September 2014 - ghc-tickets

[GHC] #9602: compiling arithmoi with llvm 3.5.0-2.1 generates an LLVM compilation error
by GHC 17 Sep '14

17 Sep '14

#9602: compiling arithmoi with llvm 3.5.0-2.1 generates an LLVM compilation error -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello. I know llvm 3.5.0 is not supported by GHC, but I thought it might be nice to have a report of a problem with it for the time when someone wants to start supporting it. I'm sorry if this is not a bug with GHC. I tried to compile arithmoi-0.4.1.1 via cabal install and here is the output received: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ cabal --version cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library $ uname -a Linux hostname 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux $ pacman -Q llvm llvm 3.5.0-2.1 $ cabal install arithmoi-0.4.1.1 Resolving dependencies... Configuring arithmoi-0.4.1.1... Building arithmoi-0.4.1.1... Preprocessing library arithmoi-0.4.1.1... [ 1 of 34] Compiling Math.NumberTheory.Primes.Sieve.Indexing ( Math/NumberTheory/Primes/Sieve/Indexing.hs, dist/dist-sandbox- f1ff1bf8/build/Math/NumberTheory/Primes/Sieve/Indexing.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_Szh_static_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_Izh_static_info$alias" Alias must point to a definition i8* @"base_GHCziReal_zdp1Integral_info$alias" Alias must point to a definition i8* @"stg_upd_frame_info$alias" Alias must point to a definition i8* @"base_GHCziReal_zdp1Real_info$alias" Alias must point to a definition i8* @"stg_ap_p_info$alias" Alias must point to a definition i8* @"base_GHCziNum_fromInteger_info$alias" Alias must point to a definition i8* @"base_GHCziReal_toInteger_info$alias" Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_integerToInt_info$alias" Alias must point to a definition i8* @"stg_ap_0_fast$alias" Alias must point to a definition i8* @"stg_ap_pp_info$alias" Alias must point to a definition i8* @"base_GHCziNum_zm_info$alias" Alias must point to a definition i8* @"stg_gc_unbx_r1$alias" Alias must point to a definition i8* @"base_GHCziReal_quotRem_info$alias" Alias must point to a definition i8* @"stg_sel_1_upd_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_Izh_con_info$alias" Alias must point to a definition i8* @"stg_sel_0_upd_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTuple_Z2T_con_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_ZC_static_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_ZMZN_closure$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTuple_Z0T_closure$alias" Alias must point to a definition i8* @"stg_newByteArrayzh$alias" Alias must point to a definition i8* @"stg_gc_unpt_r1$alias" Alias must point to a definition i8* @"arrayzm0zi5zi0zi0_DataziArrayziBase_UArray_con_info$alias" Alias must point to a definition i8* @"newCAF$alias" Alias must point to a definition i8* @"stg_bh_upd_frame_info$alias" Alias must point to a definition i8* @"base_GHCziST_runSTRep_info$alias" Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_smallInteger_info$alias" Alias must point to a definition i8* @"stg_ap_p_fast$alias" Alias must point to a definition i8* @"stg_ap_pp_fast$alias" LLVM ERROR: Broken module found, compilation aborted! Failed to install arithmoi-0.4.1.1 cabal: Error: some packages failed to install: arithmoi-0.4.1.1 failed during the building phase. The exception was: ExitFailure 1 }}} Ryan -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7015: Add support for 'static'
by GHC 17 Sep '14

17 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by luite): I agree with simonpj and rwbarton. My suggestion in the phab discussion (generating foreign exports) was merely something that could be done with the current tools, but now that the patch is going to be rewritten/improved there may be better options. Other than getting memory management sorted out, I think these are the minimum requirements to make it possible to implement static values properly on different backends: * GHC should explicitly keep track of all static metadata (hi files probably) * Static names would propagate like typeclass instances * It should be possible to build a list (like the Static Pointer Table) at link time for a library or program (and if desired, build a program that can produce this list at runtime) * `StaticName` should be reasonably robust against minor variations between compiles/backends * no backend/platform specific internal names * a source code location as an identifier for generated names is better than a simple counter * at least some simple safeguard against constructing an ill-typed heap object (like a type fingerprint) should be there As an aside, I think it would be really useful if there was a way to send type details with a more complete serialization of the construction (in terms of `Typeable`/`TypeRep` or similar) in the `StaticName` or at a higher level: * It would be possible to generate a more readable type error message if a fingerprint does not match (rather than using `show` on both sides) * Languages like Python and JavaScript could dynamically convert values * In conjunction with `GHC.Generics` or `Data.Data` one could use this to generate user interfaces that allow typesafe structured construction/editing of arguments (and dictionaries, when supported) And a final point on my wish list: It would be very useful if the `static` keyword for toplevel bindings would result in a `StaticName` that uses the original function name, rather than some generated name: {{{ #!haskell import qualified Data.Map as M -- this would guarantee that concat is in the static list concat :: [[a]] -> [a] concat = static (foldr (++) []) -- for functions that do pattern matching we could introduce a pragma {-# STATIC and #-} and :: [Bool] -> Bool and [] = True and (x:xs) = x && and xs -- or for exposing functions from other modules {-# STATIC M.fromList #-} }}} This would make it easier to have asymmetric CH programs, where one part is merely the callee, but does not include the code where the result from the call is used. I think this could also useful to implement a more flexible foreign exports mechanism for GHCJS, see https://github.com/ghcjs/ghcjs/issues/194 for some discussion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 17 Sep '14

17 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): I've made a major update to the wiki page. Here are a few things worth pointing out: In [wiki:InjectiveTypeFamilies#Proposedsyntax this section] I've listed all the syntax proposals made so far. I've also [http://www.haskell.org/pipermail/haskell-cafe/2014-September/116065.html mailed Haskell-cafe] so we can get some feedback from the community. I christened various flavours of injectivity as A, B and C :-) -- see [wiki:InjectiveTypeFamilies#Formsofinjectivity this section]. I will refer to them as such in the rest of this comment. I mailed Conal Elliot and he says he does not remember what was his use case for type families injective in only one argument. This means we only have use cases of the form A shown by Simon. Given that, I believe that it is best if we limit ourselves to implementing A. We can revise this design later if someone demonstrates compelling examples of B or C. I have outlined my idea for the algorithm that would verify users injectivity declarations in [wiki:InjectiveTypeFamilies#Implementationoutline this section]. Simon, please tell me if there are any misconceptions about how GHC's type inference works. After some thinking I am against inferring injectivity for closed type families - see my arguments in [wiki:InjectiveTypeFamilies#Inferringinjectivity this section]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:67> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7015: Add support for 'static'
by GHC 17 Sep '14

17 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a comment from Phab that should feed into the design: The current implementation does not appear to keep the heap references alive correctly: {{{ {-# LANGUAGE StaticValues #-} module Main where import GHC.Ref import Control.Concurrent import System.Environment import System.Mem import System.Mem.Weak import Data.Numbers.Primes -- from Numbers -- Just a Ref to some CAF from another package so that we can deRef it when linked with -dynamic primes_ref :: Ref [Integer] primes_ref = static primes main = do as <- getArgs let z = primes!!(length as+200) print z performGC -- addFinalizer z (putStrLn "finalizer z") print z performGC threadDelay 1000000 print . fmap (!!300) =<< deRef primes_ref -- uncommenting the next line keeps primes alive and prevents the segfault -- print (primes!!300) }}} and {{{ $ ghc -dynamic -o primes primes.hs [1 of 1] Compiling Main ( primes.hs, primes.o ) Linking primes ... $ ./primes 1229 1229 Segmentation fault (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7015: Add support for 'static'
by GHC 16 Sep '14

16 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Agreed. No way should the design mandate any particular implementation for `unStatic`! My current proposals are outlined here [blog:simonpj/StaticPointers]. There is haze around Plan A/B/C near the end, but I'm veering towards some variant of Plan A. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7015: Add support for 'static'
by GHC 16 Sep '14

16 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by rwbarton): I would just like to echo comment:16: it would be REALLY great not to commit to a particular implementation of `unStatic` such as `dlsym()`; in particular the GHCJS backend should be able to have its implementation of the same functionality, with compatible `StaticName` serializations (if not downright compatible `StaticName` types). That opens up very interesting possibilities for pure Haskell client/server web applications. As a more technical point, since GHCJS does dead code elimination, there should be some means by which the GHCJS code generator can know which top- level values are the referents of `static` expressions, so it can treat them as live, without having to pessimistically assume that everything is live. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9400: poor performance when compiling modules with many Text literals at -O1
by GHC 16 Sep '14

16 Sep '14

#9400: poor performance when compiling modules with many Text literals at -O1 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: #9370 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Spawned from #9370; see there for original discussion) Unpack the xmlhtml package and edit `src/Text/XmlHtml/HTML/Meta.hs` and remove the `OPTIONS_GHC` line at the top of the file that disables optimizations and build with `cabal buidl`. Then GHC takes ~1.5GB and over a minute to build this single module. Preliminary investigation indicates that Text's fromString and its constituent parts is being inlined repeatedly: {{{ Inlining done: Data.String.fromString Inlining done: Data.Text.$fIsStringText Inlining done: Data.Text.pack Inlining done: Data.Text.Internal.Fusion.unstream Inlining done: Data.Text.Internal.Fusion.Common.map Inlining done: Data.Text.Internal.Fusion.Common.streamList Inlining done: Data.Text.Internal.safe Inlining done: Data.Bits.$fBitsInt_$c.&. Inlining done: Data.Text.Internal.Fusion.Types.$WYield [ repeats ~4000 times ] }}} resulting in a very large intermediate program: {{{ *** Checking old interface for xmlhtml-0.2.3.2:Text.XmlHtml.HTML.Meta: [ 1 of 10] Compiling Text.XmlHtml.HTML.Meta ( src/Text/XmlHtml/HTML/Meta.hs, dist/build/Text/XmlHtml/HTML/Meta.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 26,260, types: 20,021, coercions: 0} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 1,446,658, types: 953,432, coercions: 314,352} ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 16 Sep '14

16 Sep '14

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D194 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D194 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 16 Sep '14

16 Sep '14

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 6.6.1 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 16 Sep '14

16 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D202 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0