April 2015 - ghc-tickets

[GHC] #8156: amd64 + in-tree gmp build broken
by GHC 22 Jan '17

22 Jan '17

#8156: amd64 + in-tree gmp build broken -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: #4022 #4366 #4374 | -------------------------------------+------------------------------------- Currently, the GHC build system has an in-tree GMP. This GMP seems to be used only if there is no usable GMP found on the system and the user didn't provide one using configure flags. When we build GHC using an external shared version of GMP, the resulting GHC is dynamically linked against GMP and also the generated programs are linked dynamically against GMP. When the in-tree GMP is used, it is built statically, even if the GHC we are building is shared GHC on GNU/Linux. This feature is currently broken on amd64 (#4366, #4022), but is working currently very well on Linux i686. Apart from the breakage this setting is very flexible and I'd be very happy if it were possible to keep it, in spite of removeal requests like #4374. When there is a system GMP, nothing would change, this is the most typical usage, e.g. distributions are all building this way. On the other hand, if the user removes his GMP (maybe we should provide an option to explicity trigger this in ./configure, instead of having to remove GMP); she can build a GHC that is not linked dynamically against GMP and the resulting programs are not linked either. This makes it possible to generate binaries that link dynamically against libc (no -static) which is quite compatible amongst versions, but doesn't require a libgmp.so to run. For binary deployments this seems to be the best kind of setup nowadays. Now, if we were only able to fix this for amd64. See this: https://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 On amd64 we can continue to compile GMP statically and link into the binary library, we just have to compile GMP with the fPIC. I attached the patch to fix this. Previously a similar patch has been rejected in #4022 because "this shouldn't be platform specific", but this is clearly not the case, this is specific to amd64. Tadaaaam: {{{ errge@sid64:~/ghc/inplace/bin$ cat test.hs main = print (2^100) errge@sid64:~/ghc/inplace/bin$ ./ghc-stage2 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... errge@sid64:~/ghc/inplace/bin$ ./test 1267650600228229401496703205376 errge@sid64:~/ghc/inplace/bin$ ldd ./test linux-vdso.so.1 (0x00007fff79962000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b9a83000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b987a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b9676000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b92c6000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b90a6000) /lib64/ld-linux-x86-64.so.2 (0x00007fe4b9d83000) }}} No GMP! I attach the build file patch to the bugreport. So, can we please apply this patch and just keep the in-tree GMP? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9223: Type equality makes type variable untouchable
by GHC 21 Jan '17

21 Jan '17

#9223: Type equality makes type variable untouchable -------------------------------------------+------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This doesn't look right: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} type family TF (m :: * -> *) run1 :: (forall m . Monad m => m a) -> a run1 = undefined run2 :: (forall m . (Monad m, TF m ~ ()) => m a) -> a run2 = undefined -- this works x1 = run1 (return ()) -- this fails x2 = run2 (return ()) {- Couldn't match expected type ‘a’ with actual type ‘()’ ‘a’ is untouchable inside the constraints (Monad m, TF m ~ ()) bound by a type expected by the context: (Monad m, TF m ~ ()) => m a at untouchable.hs:15:6-21 ‘a’ is a rigid type variable bound by the inferred type of x2 :: a at untouchable.hs:15:1 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ‘return’, namely ‘()’ In the first argument of ‘run2’, namely ‘(return ())’ -} }}} I would expect x2 to type check just like x1 does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9137: A way to match RULES only for literals
by GHC 16 Jan '17

16 Jan '17

#9137: A way to match RULES only for literals ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `GHC/Enum` we have {{{ {-# RULES "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = up_fb c n x 1 #-} -- This rule ensures that in the common case (delta = 1), we do not do the check here, -- and also that we have the chance to inline up_fb, which would allow the constructor to be -- inlined and good things to happen. -- We do not do it for Int this way because hand-tuned code already exists, and -- the special case varies more from the general case, due to the issue of overflows. }}} This rule would be useful for all literals, not just for `1`. I remember a discussion that such a rule would be more useful if we had a way to specify that, for example (random syntax). {-# RULES "enumDeltaToInteger1" [0] forall c n x d . isLiteral d => enumDeltaToIntegerFB c n x d = up_fb c n x d #-} I’m reporting this now to be able to link to it from #9136, where this feature might also help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10073: Idris REPL is pretty and we can too
by GHC 14 Jan '17

14 Jan '17

#10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Manual for configuring colors in the Idris REPL: https://github.com/idris- lang/Idris-dev/wiki/Manual#colours Screenshot: http://i.imgur.com/rYHCI4T.png Particularly, I'd like to make type errors and warnings more visually distinct. I think little touches like this can go a long way to making it nice to work with Haskell code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10083: ghc: panic! (the 'impossible' happened)
by GHC 12 Jan '17

12 Jan '17

#10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I used hprotoc to generate some code for Google protocol buffers. The QueryValue.proto file is attached. You can install hprotoc tool using cabal. then use ''hprotoc QueryValue.proto'' to generate code. Then create a minimal cabal file. ''cabal init -m --is-library -n'' Then if you build it with '''optimization enabled''', the build will fail ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sEMq{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 59242 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #10262: Improve documentation of module signatures
by GHC 11 Jan '17

11 Jan '17

#10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Operating System: Unknown/Multiple Keywords: backpack | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Out of curiosity, I read the bit in the user manual about the new module signatures, and I find the text a little confusing. Could those in the know clarify the points below in the manual? Thanks! * (typo) The first example refers to `String.hs`. I think you mean `Text.hs`. * Is there a way to use module signatures to deal with mutually recursive modules? The example with `TextSig` seems to require that both `Text` and `TextSig` are compiled before `A`. * Could you provide an example of specifying multiple signature/implementation pairs with `--make`? * The manual says that the dialect of Haskell used in signature files is "essentially" the same as with hs-boot files. Are there any differences? * The most recent paragraph addition doesn't make sense to me, starting with "Signatures can be installed like ordinary modules". What do you mean by "installed"? What does it mean to bring multiple signatures into scope by the same name? Can two signatures have the same name? Wouldn't their filenames also need to be the same? * Is there currently any facility available to have multiple implementations of one signature? Of course, this is all work in progress, and I don't necessarily expect an immediate fix. But, when it's nearing completion, it may be worth revisiting this stretch of text. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8761: Make pattern synonyms work with Template Haskell
by GHC 10 Jan '17

10 Jan '17

#8761: Make pattern synonyms work with Template Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Template Haskell has no support for pattern synonyms. This should be added. Specifically: * Create syntax in `Language.Haskell.TH.Syntax` and corresponding functions in `Language.Haskell.TH.Lib` * Support in !DsMeta for desugaring pattern synonym quotations. See `rep_bind`. * Support in Convert for splicing in pattern synonyms. * Support in !TcSplice for reifying pattern synonyms. See `reifyThing`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9748: Disambiguate IO actions in GHCi with :set +t
by GHC 06 Jan '17

06 Jan '17

#9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently GHCi's `:set +t` displays the same type for the following: {{{#!hs % ghci -ignore-dot-ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char Prelude> return 'a' :: IO Char 'a' it :: Char }}} A user at `#haskell-beginners` ran into a problem where they mistook an expression that defaulted to IO for a pure expression (`Id . even <$> pure 5`), `:set +t` was suggested but ended up showing the incorrect type: {{{#!hs ghci> Id . even <$> pure 5 Id False it :: Id Bool }}} This is bad for pedagogical reasons, it would be an improvement to display the following: {{{#!hs Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char <- return 'a' :: IO Char Prelude> return 'a' :: IO Char 'a' it :: Char <- return 'a' :: IO Char }}} mirroring existing syntax: {{{#!hs Prelude> :set -XScopedTypeVariables Prelude> a :: Char <- return 'a' :: IO Char a :: Char }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10352: Properly link Haskell shared libs on ELF systems
by GHC 05 Jan '17

05 Jan '17

#10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.11 system | Operating System: Linux Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since the early days of building Haskell shared libs on Linux we have been using a scheme that is really a bit of a hack. We should do it properly. In my blog post on this from 2009 (http://www.well-typed.com/blog/30/) I said: > If we use ldd again to look at the libfoo.so that we've made we will notice that it is missing a dependency on the rts library. This is problem that we've yet to sort out, so for the moment we can just add the dependency ourselves: > > $ ghc --make -dynamic -shared -fPIC Foo.hs -o libfoo.so \ > -lHSrts-ghc6.11 -optl-Wl,-rpath,/opt/ghc/lib/ghc-6.11/ > > The reason it's not linked in yet is because we need to be able to switch which version of the rts we're using without having to relink every library. For example we want to be able to switch between the debug, threaded and normal rts versions. It's quite possible to do this and it just needs a bit more rearranging in the build system to sort it out. Once it's done you'll even be able to switch rts at runtime, eg: > > $ LD_PRELOAD=/opt/ghc/lib/ghc-6.11/libHSrts_debug-ghc6.11.so > $ ./Hello So in general, if a shared lib requires symbols from another shared lib then it should depend on it. In ELF terminology that means a NEEDED entry to say this lib needs that other lib. This is important to be able to link and load these shared libraries, otherwise they can have dangling dependencies. But we don't do this. For the specific case of the RTS we do not link Haskell shared libs against the RTS. So they have lots of dangling symbols. These libraries cannot be loaded on their own, e.g. with `dlopen()`. This is bad, and has other knock-on consequences. Why don't we link to the RTS? It's because historically (with static linking) GHC had had the ability to select the flavour of the RTS when final executables are linked, not when intermediate libraries are created. This works because the RTS flavours share a common ABI. This is a useful feature as it lets us select the SMP or debug or other RTS at final link time. So when we made up the first shared lib scheme on ELF we had to support this. Our initial scheme was like this: don't link Haskell library DSOs against the RTS, only like the final exe against the RTS. Each RTS flavour has a separate SONAME, e.g. `libHSrts_thr-ghc7.8.4.so` or `libHSrts_debug- ghc7.8.4.so`. This works because the runtime linker looks at the final exe first and loads the RTS, and then when other libs are loaded the symbols all resolve. Why can't we link all the libraries against the RTS? Currently each RTS flavour has a different SONAME, which is the key that the dynamic linker uses to identify each library. So if we did link all the Haskell libs against "the" RTS we would have to pick which one at the point at which we create the library, and that'd stop us from being able to choose later. So, can we use a better scheme? We want one that doesn't leave dangling undefined references in intermediate Haskell libs, and is also compatible with the ability to select the flavour of the RTS at final exe link time (or even override it at load time). Yes we can! The first thing to note is that to be interchangeable, all the RTS flavours (that share a compatible ABI) need to have the same SONAME. So for example, all the (non-profiling) RTS DSO files have to have the internal SONAME of `libHSrts-ghc7.8.4.so`. Once they all have the same SONAME, then it's ok for all the Haskell libs to specify a NEEDED dependency on that rts SONAME. But if they have the same SONAME, what do the files get called, where do they live and how are they found? The trick is to make use of the search path. Put each RTS flavour in a different directory, but otherwise with the same filename, e.g. `lib/rts-1.0/thr/libHSrts-ghc7.8.4.so`, `lib/rts-1.0/debug/libHSrts-ghc7.8.4.so` etc. Each library DSO and exe has its list of NEEDED entries, and it has an RPATH entry used to find those libraries if they're not loaded yet. The key is the "if they're not loaded yet" bit. Remember that the linker uses the SONAME as the key to decide if the lib is loaded yet or not. So the libraries could all have an RPATH entry to say to look for the RTS in the directory containing the default RTS flavour. But then the top level exe (or foreign/export shared lib) can also link to the RTS directly (ie an NEEDED entry) and can specify an RPATH which can be for any of the rts flavours. When the linker loads the top level exe, it will loads the selected RTS using the exe's RPATH, and then when the linker sees other Haskell libs that have a NEEDED entry on the RTS it will ignore them because the RTS's SONAME is already loaded. So concretely, instead of: lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_debug-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_debug-ghc${ver}.so each with a different SONAME we'd have lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/debug/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_debug/libHSrts-ghc${ver}.so each with the same SONAME When linking libs we would always use `-lHSrts -rpath lib/ghc-${ver}/rts-1.0` When linking exes (or shared libs for external consumption) we would use both `-lHSrts` and `-rpath lib/ghc-${ver}/${rtsflavour}/rts-1.0`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference
by GHC 05 Jan '17

05 Jan '17

#9248: Document -XHaskell98 and -XHaskell2010 in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3