October 2015 - ghc-tickets

[GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp)
by GHC 23 May '16

23 May '16

#8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Example: {{{ [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "119871672") ,("num_GCs", "100") ,("average_bytes_used", "4388904") ,("max_bytes_used", "12539576") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "27") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.10") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.15") ] [ezyang@hs01 compiler]$ rm T6048.hi [ezyang@hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "121022912") ,("num_GCs", "100") ,("average_bytes_used", "4022069") ,("max_bytes_used", "11224944") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "25") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.11") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.14") ] }}} It's a slight but present difference: I noticed because one of the perf tests was failing on an initial run of the test suite, but passing when I re-ran it. There are two possible bugs here. One is that our implementation of `-fforce-recomp` is buggy and we shouldn't be reading in the hi file at all if `-fforce-recomp` is on; the other is that we should always clean up interface files before running one of these perf tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11033: ghc 7.10.2 testsuite: "DoParamM(normal)" test fails
by GHC 23 May '16

23 May '16

#11033: ghc 7.10.2 testsuite: "DoParamM(normal)" test fails --------------------------------------+--------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- In the log: {{{ =====> DoParamM(normal) 13 of 4142 [0, 0, 0] cd ./rebindable && "/usr/local/bin/ghc" -c DoParamM.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history > DoParamM.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./rebindable/DoParamM.stderr 2014-12-23 02:31:11.000000000 +0000 +++ ./rebindable/DoParamM.comp.stderr 2015-10-29 10:21:12.520000000 +0000 @@ -1,25 +1,20 @@ DoParamM.hs:146:25: - Couldn't match expected type `Int' with actual type `Char' - In the second argument of `(==)', namely v' - In the first argument of `return', namely `(v == v')' - In a stmt of a 'do' block: return (v == v') + Couldn't match expected type ‘Int’ with actual type ‘Char’ + In the second argument of ‘(==)’, namely ‘v'’ + In the first argument of ‘return’, namely ‘(v == v')’ DoParamM.hs:286:28: - Couldn't match type `Unlocked' with `Locked' + Couldn't match type ‘Unlocked’ with ‘Locked’ Expected type: LIO Locked Locked () Actual type: LIO Unlocked Locked () In a stmt of a 'do' block: tlock2_do In the expression: do { tlock2_do; tlock2_do } - In an equation for `tlock4_do': - tlock4_do - = do { tlock2_do; - tlock2_do } DoParamM.hs:302:37: - Couldn't match type `Locked' with `Unlocked' + Couldn't match type ‘Locked’ with ‘Unlocked’ Expected type: LIO Unlocked Unlocked () Actual type: LIO Locked Unlocked () In a stmt of a 'do' block: unlock @@ -27,8 +22,3 @@ do { tlock2_do; unlock; unlock } - In an equation for `tlock4'_do': - tlock4'_do - = do { tlock2_do; - unlock; - unlock } *** unexpected failure for DoParamM(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11033> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC
by GHC 23 May '16

23 May '16

#10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC -----------------------------------------+---------------------------- Reporter: howarth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+---------------------------- Using the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 binary release to install ghc 7.10.1 with... ./configure --prefix=/sw make DESTDIR=/sw install fails to install a populated /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC subdirectory causing builds of ghc packages with gcc-prim dependencies to fail. The only non- documentation files installed are... -rwxr-xr-x root/admin 647620 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib -rw-r--r-- root/admin 1326504 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.a -rw-r--r-- root/admin 814 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/package.conf.d/ghc- prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166.conf This compares to the same installation of the ghc-7.8.3-x86_64-apple- darwin.tar.bz2 binary release which does install the required files as... drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/ drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/ -rw-r--r-- root/admin 373897 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.dyn_hi -rw-r--r-- root/admin 373885 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.hi -rw-r--r-- root/admin 373889 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.p_hi -rw-r--r-- root/admin 2661 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.dyn_hi -rw-r--r-- root/admin 2649 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.hi -rw-r--r-- root/admin 2653 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.p_hi -rw-r--r-- root/admin 1940 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.dyn_hi -rw-r--r-- root/admin 1928 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.hi -rw-r--r-- root/admin 1932 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.p_hi -rw-r--r-- root/admin 942 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.dyn_hi -rw-r--r-- root/admin 930 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.hi -rw-r--r-- root/admin 934 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.p_hi -rw-r--r-- root/admin 388 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.dyn_hi -rw-r--r-- root/admin 376 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.hi -rw-r--r-- root/admin 380 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.p_hi -rw-r--r-- root/admin 50032 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.dyn_hi -rw-r--r-- root/admin 50020 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.hi -rw-r--r-- root/admin 50024 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.p_hi -rw-r--r-- root/admin 1100 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.dyn_hi -rw-r--r-- root/admin 1088 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.hi -rw-r--r-- root/admin 1092 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.p_hi -rw-r--r-- root/admin 939 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.dyn_hi -rw-r--r-- root/admin 927 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.hi -rw-r--r-- root/admin 931 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.p_hi -rwxr-xr-x root/admin 631192 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib -rw-r--r-- root/admin 792352 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0.a -rw-r--r-- root/admin 1134504 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0_p.a -rw-r--r-- root/admin 871 2015-07-01 13:09 ./sw/lib/ghc-7.8.3/package.conf.d/ghc- prim-0.3.1.0-954cb57749cf319beafdc89b3415422c.conf -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9095: make sdist picks up test files
by GHC 22 May '16

22 May '16

#9095: make sdist picks up test files ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I recently ran 'make sdist' and discovered that I my source tarball was nearly a gigabyte large. Closer inspection revealed that sdist had slurped up executable files for tests that I had run at some point. It would be preferable if 'make sdist' did not do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10961: Make it possible to purely use the parser
by GHC 21 May '16

21 May '16

#10961: Make it possible to purely use the parser -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is claimed that the parser is pure but one of the arguments is `DynFlags`. The only safe way to construct a copy of `DynFlags` requires IO so it is not possible to use the parser purely. I propose to introduce a new datatype `ParserOptions` which contains the options used by the parser and a function `DynFlags -> ParserOptions` so that it is possible to purely construct a `ParserOptions` and use the parser purely. This would be useful for external users of the parser. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10961> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9298: ghc.exe: internal error: evacuate: strange closure type 365488164
by GHC 21 May '16

21 May '16

#9298: ghc.exe: internal error: evacuate: strange closure type 365488164 ------------------------------+--------------------------------------- Reporter: Tominator2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: idris | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+--------------------------------------- after saying "cabal install idris" the machine churned for a while, spitting out messages, then said: src\Idris\AbsSyntax.hs:1569:10: Warning: `EitherErr' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. ghc.exe: internal error: evacuate: strange closure type 365488164 (GHC version 7.8.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Failed to install idris-0.9.13.1 cabal.exe: Error: some packages failed to install: idris-0.9.13.1 failed during the building phase. The exception was: ExitFailure 3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9059: Excessive space usage while generating code for fractional literals with big exponents
by GHC 19 May '16

19 May '16

#9059: Excessive space usage while generating code for fractional literals with big exponents ------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Generating (byte-)code for fractional literals with big exponents causes excessive space usage: {{{ $ ghci -ddump-bcos GHCi, version 7.6.3: 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> let r=1e1000 :: Rational ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_so4 = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_so4#0 []: let sat_snX = ... in ... bitmap: 0 [] PUSH_UBX (1) 1 PACK GHC.Integer.Type.S# 1 ALLOC_AP 0 PUSH_BCO ProtoBCO sat_snY#0 []: let sat_siH = ... in ... bitmap: 0 [] STKCHECK 544 PUSH_UBX (1) 30 PACK GHC.Types.I# 1 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_UBX (1) 953884573 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1777164331 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1665817172 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1937337765 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 799142572 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1439062260 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 1049546550 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 580758741 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 PUSH_UBX (1) 139570364 PACK GHC.Types.I# 1 PUSH_LL 1 0 PACK : 2 ... }}} Increasing the exponent to say a 1000000 will quickly fill up the memory of my machine. A similar problem occurs while compiling: !BigExponentBug.hs: {{{ module BigExponentBug (r) where r = 1e100 :: Rational }}} {{{ ghc --make BigExponentBug.hs -ddump-simpl [1 of 1] Compiling BigExponentBug ( BigExponentBug.hs, BigExponentBug.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 9, types: 5, coercions: 0} BigExponentBug.r :: GHC.Real.Rational [GblId] BigExponentBug.r = GHC.Real.fromRational @ GHC.Real.Rational (GHC.Real.$fFractionalRatio @ GHC.Integer.Type.Integer (GHC.Real.$fNumRatio @ GHC.Integer.Type.Integer GHC.Real.$fIntegralInteger) GHC.Real.$fIntegralInteger) (GHC.Real.:% @ GHC.Integer.Type.Integer (__integer 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) (__integer 1)) }}} Again increasing the exponent to 1000000 quickly invokes the OOM killer on my machine. P.S. This bug was discovered while fixing a [https://github.com/bos/aeson/issues/198 related bug] in `aeson`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #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] #10333: hs-boot modification doesn't induce recompilation
by GHC 16 May '16

16 May '16

#10333: hs-boot modification doesn't induce recompilation -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider these modules: X.hs-boot {{{ module X where }}} Y.hs {{{ module Y where import {-# SOURCE #-} X data T = T data S = S T }}} X.hs {{{ module X where import Y }}} `ghc --make Y.hs` will compile fine. Now, modify `X.hs-boot` to add a `data T` (which will cause an ambiguous identifier error in Y.hx`. Run `ghc --make Y.hs` and nothing happens! (You might also notice something else a bit funny, which is that `X.hs` gets compiled, even though it's not directly in the import chain of Y. I think this might be intentional but I'm not sure.) Discovered this while poking around #10182. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6