- ghc-tickets - Haskell.org

[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do
by GHC 11 Dec '18

11 Dec '18

#9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | 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: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the `TidyPgm` pass is forced to predict, accurately but unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do. Reason: * Each `Id` in the interface file records (among other things) the '''arity''' of the `Id`, and whether it has '''CAF references''' * We really only know these two things for sure after `CorePrep`. The conversion from Core to STG makes no structural changes. * However the result of `TidyPgm` (which preceded `CorePrep`) is used to generate the interface file. So it has to predict the arity and CAF-ref status of each `Id`. * This is not good. It restricts what `CorePrep` can do (notably, it must not change the arity of a top-level `Id`), and it leads to unsavoury code (e.g. look at the call to `CorePrep.cvtLitInteger` in `TidyPgm.cafRefsL`. It's also dangerous: an inconsistency could lead to a crash. This is a long-standing problem. My current thought for how to unravel it is this: * `TidyPgm` does not attach arity or CAF-ref info. * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity and CAF-ref info * Then use that auxiliary mapping during the conversion from tidied program to `ModIface`. I don't think this would be hard. It would mean that the tidied program and the core-prep'd program would have to exist in memory at the same time. An alternative would be to generate the `ModIface` from the tidied program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to add arity and CAF-ref info. (You'd have to do this before generating the fingerprints.) The advantage of this is that the `ModIface` can be a lot smaller than the code for the entire module. A long-standing wart which needs some careful attention. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

Re: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust
by GHC 11 Dec '18

11 Dec '18

#4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: (none) Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.12.2 Resolution: duplicate | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => duplicate * related: => #9718 Comment: Duplicate of #9718. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4121#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16024: Kind Signatures on data instances
by GHC 10 Dec '18

10 Dec '18

#16024: Kind Signatures on data instances -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- There's a comment in `compiler/typecheck/TcInstDcls.hs` that reads: > The "header" is the part other than the data constructors themselves > e.g. `data instance D [a] :: * -> * = ...` > Here the "header" is the bit before the "=" sign What's weird is that you cannot actually compile code that this example suggests is valid. Consider this: {{{ {-# language TypeFamilies #-} module BadSig where data family Bar a :: * data instance Bar Int :: * = Bool }}} It fails on GHC 8.6.2 with: {{{ bad_sig.hs:6:28: error: parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' | 6 | data instance Bar Int :: * = Bool | ^ }}} Oddly, GHC will accept the instance if the body is missing: {{{ {-# language TypeFamilies #-} module BadSig where data family Bar a :: * data instance Bar Int :: * }}} It is not clear to me whether or not this one should be accepted, but that is beside the point. The first example should certainly be accepted. It should also be accepted with `TYPE 'LiftedRep` instead of `*`, but it fails with the same parser error when given that kind signature as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16022: Hadrian appears to link against libffi unconditionally
by GHC 10 Dec '18

10 Dec '18

#16022: Hadrian appears to link against libffi unconditionally -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Hadrian appears to be linking against `libffi`, even on platforms where it should not be used. I suspect the cause is that Hadrian makes no attempt to set the `ffi` flag when configuring `rts`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16016: Hadrian build fails on FreeBSD
by GHC 10 Dec '18

10 Dec '18

#16016: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- A plain hadrian build using `hadrian/build.cabal.sh` fails with {{{ /---------------------------------------------------------------------------------\ | Successfully built program 'ghc-pkg' (Stage0). | | Executable: _build/stage0/bin/ghc-pkg | | Program synopsis: A utility for querying and managing the GHC package database. | \---------------------------------------------------------------------------------/ hadrian: '/usr/home/ben/ghc/_build/stage0/bin/ghc' exited with an error: ghc: missing -B<dir> option shakeArgsWith 0.000s 0% Function shake 0.392s 0% Database read 0.000s 0% With database 0.000s 0% Running rules 1725.240s 99% ========================= Total 1725.633s 100% Error when running Shake build system: at src/Rules.hs:(32,19)-(45,17): at src/Rules.hs:45:5-17: * Depends on: _build/stage1/lib/bin/unlit at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (PackageDataFile (Context {stage = Stage1, package = Package {pkgLanguage = Haskell, pkgType = Program, pkgName = "unlit", pkgPath = "utils/unlit"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:200:5-36: * Depends on: _build/stage1/utils/unlit/setup-config * Raised the exception: ExitFailure 1 }}} on FreeBSD 11 on amd64. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15769: GHC 8.6 for macOS depends on homebrew
by GHC 10 Dec '18

10 Dec '18

#15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I guess the ghc-8.6.1-x86_64-apple-darwin.tar.xz is build with homebrew. So, it depends on homebrew's "libgmp". Since I'm using MacPorts, the following error occurs on installation: {{{ % sudo make install "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/usr/local/ghc-8.6.1' '/usr/local/ghc-8.6.1/lib/ghc-8.6.1' '/usr/local/ghc-8.6.1/share/doc/ghc-8.6.1/html/libraries' 'v p dyn' dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: /Users/kazu/Downloads/ghc-8.6.1/libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.1.dylib Reason: image not found make[1]: *** [install_packages] Abort trap: 6 make: *** [install] Error 2 }}} After make a link from "/usr/local/opt/gmp/lib/libgmp.10.dylib" to "/opt/local/lib/libgmp.10.dylib" installed by MacPorts, the installation succeeds. But when using GHC 8.6.1, the following error occurs: {{{ [15 of 15] Compiling Network.DNS ( Network/DNS.hs, dist/build/Network/DNS.o ) ld: library not found for -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) cab: callCommand: cabal build (exit 1): failed }}} To fix this, the following is necessary: {{{ % export LIBRARY_PATH=/usr/lib:/opt/local/lib }}} - "/usr/lib" is for "libiconv" and should come first to hide "/opt/local/lib/libiconv" - "/opt/local/lib" is for "libgmp" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks
by GHC 10 Dec '18

10 Dec '18

#14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | 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: -------------------------------------+------------------------------------- In #14222 it was noted that something appears to be broken in `CmmCommonBlockElim`. Consider the program from that ticket, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} This program produces six copies of a block of the form, {{{#!c c6JT: R2 = I64[R1 + 7]; R1 = P64[Sp + 8]; Sp = Sp + 16; call $wloop_all_s6CQ_info(R2, R1) args: 8, res: 0, upd: 8; }}} in the `-ddump-opt-cmm` output, which are manifest in the assembler as, {{{#!asm block_c6JT_info: _c6JT: movq 7(%rbx),%r14 movq 8(%rbp),%rbx addq $16,%rbp jmp $wloop_all_s6CQ_info }}} CBE really ought to be catching these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #12893: Profiling defeats stream fusion when using vector library
by GHC 10 Dec '18

10 Dec '18

#12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: stream-fusion | Operating System: MacOS X profiling | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this problem where enabling profiling in Haskell undoes stream fusion and I’d like to do my profiling with stream fusion intact. The following reproduces my problem: {{{ $ git clone git@github.com:haskell-works/hw-tutorial-performance.git $ cd hw-tutorial-performance/ $ stack init $ stack build --executable-profiling $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m4.432s user 0m3.484s sys 0m0.936s $ rm -rf .stack-work/ $ stack build $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m0.034s user 0m0.018s sys 0m0.013s With profiling, my program takes over 4 seconds to run. Without profiling, it only takes 0.034 seconds. }}} The problem has nothing to do with stack. {{{ (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 115,888 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.005s 0.0049s 0.0049s INIT time 0.000s ( 0.002s elapsed) MUT time 0.010s ( 0.025s elapsed) GC time 0.000s ( 0.005s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 0.012s ( 0.037s elapsed) %GC time 1.8% (13.1% elapsed) Alloc rate 11,904,262 bytes per MUT second Productivity 97.1% of total user, 31.2% of total elapsed real 0m0.057s user 0m0.012s sys 0m0.010s (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -prof -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 3,012,099,000 bytes allocated in the heap 4,079,698,408 bytes copied during GC 1,162,199,352 bytes maximum residency (13 sample(s)) 19,313,368 bytes maximum slop 1990 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4869 colls, 0 par 1.046s 1.055s 0.0002s 0.0017s Gen 1 13 colls, 0 par 1.230s 1.960s 0.1508s 0.5764s INIT time 0.000s ( 0.004s elapsed) MUT time 0.963s ( 0.825s elapsed) GC time 2.276s ( 3.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.009s ( 0.185s elapsed) Total time 3.251s ( 4.029s elapsed) %GC time 70.0% (74.8% elapsed) Alloc rate 3,126,345,026 bytes per MUT second Productivity 30.0% of total user, 24.2% of total elapsed real 0m4.197s user 0m3.251s sys 0m0.883s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13637: Printing type operators adds extraneous parenthesis
by GHC 10 Dec '18

10 Dec '18

#13637: Printing type operators adds extraneous parenthesis -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Given the code: {{{ {-# LANGUAGE TypeOperators #-} type name ::: a = a f :: Int ::: Int -> Int f = id }}} In GHCi-8.0.2 I get: {{{ >>> :t f f :: Int ::: Int -> Int }}} But in GHCi-8.2.0.20170427 I get: {{{ >>> :t f f :: (Int ::: Int) -> Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16018: Disabling core optimizations ignores code that would otherwise warn.
by GHC 09 Dec '18

09 Dec '18

#16018: Disabling core optimizations ignores code that would otherwise warn. -------------------------------------+------------------------------------- Reporter: dmjio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Keywords: core, | Operating System: Unknown/Multiple optimizations, Wall | Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the below code snippet, {{{#!hs module Main where main :: IO () main = putStrLn "hey" data StopLight = Red | Green | Yellow deriving (Show, Eq) data Intersection = Intersection { light :: {-# UNPACK #-} !StopLight } deriving (Show, Eq) }}} The above code will warn with optimizations enabled (`ghc -Wall -O2 Main.hs`), message below: ''' Main.hs:13:5: warning: • Ignoring unusable UNPACK pragma on the first argument of ‘Intersection’ • In the definition of data constructor ‘Intersection’ In the data type declaration for ‘Intersection’ | 13 | = Intersection ''' Without optimizations, no warnings are emitted `ghc -Wall -O0 Main.hs`. The desired behavior should be a warning emitted in both cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2