March 2016 - ghc-tickets

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

24 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 24 May '16

24 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] #11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS
by GHC 23 May '16

23 May '16

#11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: ide | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHC's build system echos the GHC invocation used to build each C source file. This is incompatible with IDEs like Eclipse, which require that the actual C compiler invocation be emitted so they can determine the flags being passed to the C compiler. As a result, code assistance in Eclipse is poor. This is a feature request for mimicking the build output of a C build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #11574: schedule: re-entered unsafely on minimal hello world program on arm
by GHC 22 May '16

22 May '16

#11574: schedule: re-entered unsafely on minimal hello world program on arm -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- i installed ghc 7.10.3 from jessie-backports (together with the corresponding LLVM 1:3.5.2.3~bpo8+2) and get for the minimal main = putStrLn "hello" program the error message {{{testthree: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? }} i am not certain if this is related: cabal install for the same minimal program (with a minimal cabal file) hangs. cabal install -v gives {{{ /home/frank/.cabal/setup-exe-cache/setup-Simple-Cabal-1.22.5.0-arm-linux- ghc-7.10.3 configure --verbose=2 --ghc --prefix=/home/frank/.cabal --bindir=/home/frank/.cabal/bin --libdir=/home/frank/.cabal/lib --libsubdir=arm-linux-ghc-7.10.3/testthree-0.0.6-3AgAf9bDkWJGZdbGLvO875 --libexecdir=/home/frank/.cabal/libexec --datadir=/home/frank/.cabal/share --datasubdir=arm-linux-ghc-7.10.3/testthree-0.0.6 --docdir=/home/frank/.cabal/share/doc/arm-linux-ghc-7.10.3/testthree-0.0.6 --htmldir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --haddockdir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --sysconfdir=/home/frank/.cabal/etc --user --extra-prog-path=/home/frank/.cabal/bin --dependency=base=base-4.8.2.0-2f1f71a7fcf013cd47fd21f489064f9a --disable-tests --exact-configuration --disable-benchmarks Redirecting build log to {handle: /home/frank/.cabal/logs/testthree-0.0.6.log} }}} any comment how this can be fixed? thank you - a running 7.10.3 for armhf is a great achievement! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

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

22 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] #11297: CmmSwitchTest fails on arm
by GHC 21 May '16

21 May '16

#11297: CmmSwitchTest fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: CmmSwitchTest | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Actual stdout output differs from expected: --- /dev/null 2015-12-26 13:34:29.750000000 +0100 +++ ./codeGen/should_run/CmmSwitchTest.run.stdout.normalised 2015-12-26 22:14:17.937137588 +0100 @@ -0,0 +1,57 @@ +ERR: aj (-1) is 1337 and not 41. +ERR: ak (-11) is 1337 and not 36. +ERR: ak (-10) is 1337 and not 37. +ERR: ak (-9) is 1337 and not 37. +ERR: ak (-8) is 1337 and not 38. +ERR: ak (-7) is 1337 and not 38. +ERR: ak (-6) is 1337 and not 39. +ERR: ak (-5) is 1337 and not 39. +ERR: ak (-4) is 1337 and not 40. +ERR: ak (-3) is 1337 and not 40. +ERR: ak (-2) is 1337 and not 41. +ERR: ak (-1) is 1337 and not 41. +ERR: al (0) is 1337 and not 42. +ERR: al (1) is 1337 and not 42. +ERR: al (2) is 1337 and not 43. +ERR: al (3) is 1337 and not 43. +ERR: al (4) is 1337 and not 44. +ERR: al (5) is 1337 and not 44. +ERR: al (6) is 1337 and not 45. +ERR: al (7) is 1337 and not 45. +ERR: al (8) is 1337 and not 46. +ERR: al (9) is 1337 and not 46. +ERR: al (10) is 1337 and not 47. +ERR: al (-11) is 1337 and not 36. +ERR: al (-10) is 1337 and not 37. +ERR: al (-9) is 1337 and not 37. +ERR: al (-8) is 1337 and not 38. +ERR: al (-7) is 1337 and not 38. +ERR: al (-6) is 1337 and not 39. +ERR: al (-5) is 1337 and not 39. +ERR: al (-4) is 1337 and not 40. +ERR: al (-3) is 1337 and not 40. +ERR: al (-2) is 1337 and not 41. +ERR: al (-1) is 1337 and not 41. +ERR: ay (4294967295) is 1337 and not 41. +ERR: az (4294967285) is 1337 and not 36. +ERR: az (4294967286) is 1337 and not 37. +ERR: az (4294967287) is 1337 and not 37. +ERR: az (4294967288) is 1337 and not 38. +ERR: az (4294967289) is 1337 and not 38. +ERR: az (4294967290) is 1337 and not 39. +ERR: az (4294967291) is 1337 and not 39. +ERR: az (4294967292) is 1337 and not 40. +ERR: az (4294967293) is 1337 and not 40. +ERR: az (4294967294) is 1337 and not 41. +ERR: az (4294967295) is 1337 and not 41. +ERR: ba (4294967285) is 1337 and not 36. +ERR: ba (4294967286) is 1337 and not 37. +ERR: ba (4294967287) is 1337 and not 37. +ERR: ba (4294967288) is 1337 and not 38. +ERR: ba (4294967289) is 1337 and not 38. +ERR: ba (4294967290) is 1337 and not 39. +ERR: ba (4294967291) is 1337 and not 39. +ERR: ba (4294967292) is 1337 and not 40. +ERR: ba (4294967293) is 1337 and not 40. +ERR: ba (4294967294) is 1337 and not 41. +ERR: ba (4294967295) is 1337 and not 41. \ No newline at end of file *** unexpected failure for CmmSwitchTest(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[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] #11429: Make unrecognised `-W` flags a warning rather than an error
by GHC 19 May '16

19 May '16

#11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 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: Design/Warnings -------------------------------------+------------------------------------- Currently, it's a fatal error to pass GHC a warning flag it doesn't recognise: {{{ $ ghc-8.1.20160111 -Wfoobar -c foobar.hs ghc: unrecognised flag: -Wfoobar Usage: For basic information, try the `--help' option. }}} However, in order to gain more flexibility adding/removing warning flags without requiring users to carefully guard which flags a given GHC version supports, it was suggested to make GHC more tolerating in case of unrecognised warning flags (which may either have been removed, or not yet available in the current GHC version). Specifically, I propose the following: 1. Handle `-Wno-<token>` or `-W<token>` for an unknown `<token>` as a warning rather than an error 2. This warning gets its own token `unrecognised-warning-flag` (turned on by default), so that it can be controlled via the general warning facilities as well: - `-Wno-unrecognised-warning-flag` turns off such warnings - `-Wunrecognised-warning-flag` turns on such warnings explicitly - `-Werror=unrecognised-warning-flag` (once we have #11219) emulates the old behaviour - various other combinations with warning-sets, `-Werror` specifications -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11