April 2016 - ghc-tickets

[GHC] #11782: Teach ghc-pkg to read multiple registrations from command line
by GHC 19 May '16

19 May '16

#11782: Teach ghc-pkg to read multiple registrations from command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: ghc-pkg | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-pkg register and ghc-pkg update should take files/stdin streams which consist of multiple packages separated by `----`. ghc-pkg will operate atomically: either all of the registrations succeed or none are performed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10671: inplace/bin/ghc-stage1 doesn't respect --with-ld override
by GHC 19 May '16

19 May '16

#10671: inplace/bin/ghc-stage1 doesn't respect --with-ld override -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building ghc 7.10.1 on RHEL 5.8. I need to override the old system linker which lacks features and performance. I get stage1 built but then it forgets the override. Configure: ./configure --prefix=/home/cavtools/opt/ghc-7.10.1 --with- ld=/home/cavtools/64/pkg/bin/gld --with-ar=/home/cavtools/64/pkg/bin/gar --with-ranlib=/home/cavtools/64/pkg/bin/granlib settings: [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", ""), ("Haskell CPP command","/usr/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional "), ("ld command", "/home/cavtools/64/pkg/bin/gld"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/home/cavtools/64/pkg/bin/gar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] inplace/lib/settings: [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", ""), ("Haskell CPP command","/usr/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional "), ("ld command", "/home/cavtools/64/pkg/bin/gld"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/home/cavtools/64/pkg/bin/gar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] Failure looks like: "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -H32m -O -this-package-key ghcpr_8TmvWUcS1U1IKHT0levwg3 -hide-all- packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist- install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h -package-key rts -this-package-key ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist- install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist- install/build/GHC/IntWord64.p_o -dyno libraries/ghc-prim/dist- install/build/GHC/IntWord64.dyn_o /usr/bin/ld: unrecognized option '--build-id=none' /usr/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status But why are you using /usr/bin/ld? I told you not to use /usr/bin/ld! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11780: GHC stage-2 build fails with "relocation R_X86_64_PC32 against `exitStaticPtrTable' can not be used when making a shared object"
by GHC 19 May '16

19 May '16

#11780: GHC stage-2 build fails with "relocation R_X86_64_PC32 against `exitStaticPtrTable' can not be used when making a shared object" -------------------------------------+------------------------------------- Reporter: zadarnowski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On very old versions of CentOS (5.x) running GCC 4.1.2, GHC fails to build with the following error: {{{ /usr/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation R_X86_64_PC32 against `exitStaticPtrTable' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value }}} This appears to be caused by #pragma GCC visibility push(hidden) in BeginPrivate.h. Removing the HAS_VISIBILITY_HIDDEN macro from mk/config.h results in a successful build. BeginPrivate.h contains a comment which seems to indicate similar problem occurs with GCC 4.2.1 on FreeBSD. I suggest that the #if directive in {Begin,End}Private.h be changed to cover both systems, by enabling visibility pragmas only on GCC versions higher than 4.2 as follows: {{{ #if defined(HAS_VISIBLITY_HIDDEN) && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2) }}} Old versions of CentOS are still prolific in enterprise environments so it would be great for advocacy reasons to get that fix into the next release of GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11761: autoconf 2.69 breaks configure
by GHC 18 May '16

18 May '16

#11761: autoconf 2.69 breaks configure -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- linux ppc64 buildbot reveals interesting issue which shows as following while running configure: {{{ ./configure: line 561: save_bash_input: buffer already exists for new fd 417 }}} it looks like this issue is presented in configure only when configure is generated by autoconf 2.69. On the same platform hand installed autoconf 2.68 produces working configure. I guess this is multi-platform so I do not mark platform here. Also as this is in 3th party package I'm reporting this just for the reference of known issue... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11749: Add long forms for -keep-* flags and possibly deprecate short forms
by GHC 18 May '16

18 May '16

#11749: Add long forms for -keep-* flags and possibly deprecate short forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The fact that GHC's `-keep-*` flags are short flags (e.g. begin with only one dash) is confusing and inconsistent with most of the rest of our flags, which use the typical gnu long form (with two dashes). I propose that we add `--keep-*` flags and consider deprecating the short forms at some point. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11738: A command to remove modules from the target list
by GHC 18 May '16

18 May '16

#11738: A command to remove modules from the target list -------------------------------------+------------------------------------- Reporter: jh3141 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Maybe it's because I'm a newbie, or possibly just because having the separate lists is a little confusing generally, but I quite often accidentally add a module to the target list (:a modulename) when I meant to add it to the current scope (:m +modulename). A way of *removing* the module after doing this would be useful, because it often results in errors when I use :reload. The following stack overflow question contains an answer with a suggested implementation, which could be useful: http://stackoverflow.com/questions/36139011/how-to-remove-module-from- target-list-in-ghci -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11730: GHC panics ('unload: no interpreter") during T10052 test
by GHC 18 May '16

18 May '16

#11730: GHC panics ('unload: no interpreter") during T10052 test -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- T10052.hs currently results in a runtime panic on interpreter-less GHCs: {{{ =====> T10052(normal) 7 of 8 [0, 5, 0] cd ./T10052 && $MAKE -s --no-print-directory T10052 </dev/null > T10052.run.stdout 2> T10052.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:9: recipe for target 'T10052' failed Stderr: when making flags consistent: warning: -O conflicts with --interactive; -O ignored. T10052: T10052: panic! (the 'impossible' happened) (GHC version 8.1.20160320 for x86_64-unknown-linux): unload: no interpreter Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [T10052] Error 1 *** unexpected failure for T10052(normal) }}} I'm creating this ticket in order to reference this ticket via a `expect_broken()` annotation -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit
by GHC 18 May '16

18 May '16

#11704: Word and Int literals not correctly truncated when cross compiling 64 -> 32 bit -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC does not take the target word size into account for some of the rules in `PrelRules`: {{{#!hs rule_convert "integerToWord" integerToWordName mkWordLitWord, rule_convert "integerToInt" integerToIntName mkIntLitInt, }}} The relevant code from `CoreSyn`: {{{#!hs -- | Create a machine word literal expression of type @Word#@ from a @Word@. -- If you want an expression of type @Word@ use 'MkCore.mkWordExpr' mkWordLitWord :: DynFlags -> Word -> Expr b mkWordLit dflags w = Lit (mkMachWord dflags w) mkWordLitWord dflags w = Lit (mkMachWord dflags (toInteger w)) -- | Create a machine integer literal expression of type @Int#@ from an @Int@. -- If you want an expression of type @Int@ use 'MkCore.mkIntExpr' mkIntLitInt :: DynFlags -> Int -> Expr b mkIntLitInt dflags n = Lit (mkMachInt dflags (toInteger n)) }}} If a literal is bigger than the target word size, these rules can lead to loss of truncation when optimizing a `fromInteger` / `toInteger` pair. This makes testcase `codeGen/5785.hs` fail when compiled with optimization with GHCJS on 64 bit GHC. It probably also affects targeting 64 platforms with 32 bit compilers, where literals would be truncated too much, but I don't have a way of testing that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8207: Show instance for Language in DynFlags
by GHC 17 May '16

17 May '16

#8207: Show instance for Language in DynFlags ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I feel that the GHC API could benefit from a Show instance for Language in DynFlags.hs. Currently, if we want to display the language being used we have to do something like {{{ foo inf = case hmi_language inf of Nothing -> Nothing Just Haskell98 -> Just "Haskell98" Just Haskell2010 -> Just "Haskell2010" }}} This is pretty much just the Show instance (over Maybe) and Haskell can derive it for us automatically: we just need to change `deriving Enum` to `deriving (Enum, Show)`. The above solution is not the most robust ever as if this data type is ever changed, this starts to form an incomplete pattern. If we have a catch all `_`, GHC complains about overlapping patterns. Easily solved with `show <$> hmi_language inf`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11783: Very large slowdown when using parallel garbage collector
by GHC 16 May '16

16 May '16

#11783: Very large slowdown when using parallel garbage collector -------------------------------------+------------------------------------- Reporter: luispedro | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: performance, | Operating System: Unknown/Multiple garbage collector | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As part of debugging some performance issues on an application I am writing, I concluded that the issue is in the parallel GC implemented in the GHC RTS. I extracted the code attached to make a self-contained use- case, but in my system the code runs in 16s when using a single thread, in 18s when using 6 threads but no parallel GC and in over a minute when using 6 threads with parallel GC! The true slowdown in the full code is actually worse and relevant for the application (some steps take >1 hour instead of <1 minute!). Parts of the code do take full advantage of parallel processing, this is just one simple test case -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7