August 2018 - ghc-tickets

[GHC] #15219: Implement UnliftedNewtypes proposal
by GHC 14 Feb '19

14 Feb '19

#15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple UnliftedNewtypes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The unlifted newtypes proposal is described here: https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst I am going to be working on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14848: -XDuplicateRecordFields breaks record expression splices
by GHC 10 Feb '19

10 Feb '19

#14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# language TemplateHaskell #-} {-# language DuplicateRecordFields #-} module Lib where import Language.Haskell.TH import Language.Haskell.TH.Syntax data A = A {x :: Int, y :: String} a = A 3 "test" test = $([e|case a of A {x = b} -> b|]) }}} Without `DuplicateRecordFields` it compiles correctly so `test = 3` but with `DuplicateRecordFields` enabled it gives: {{{ • Illegal variable name: ‘$sel:x:A’ When splicing a TH expression: case Lib.a of (Lib.A {Lib.$sel:x:A = b_0}) -> b_0 • In the untyped splice: $([| case a of { A {x = b} -> b } |]) }}} Additionally, there doesn't seem to be a workaround for munging the name manually, since the `$sel:x:A` name is the one actually in scope, there is no `A.x` like there would be normally, even when the label is not a duplicate. Is there a way to get around this? Ex: by changing the binding name somehow manually? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15091: Better occurrence analysis for join points
by GHC 10 Feb '19

10 Feb '19

#15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this {{{ let x = ... in join j y = x+y in case v of A -> x B -> j 1 C -> j 2 D -> 3 }}} What does `OccAnal` say about `x`'s usage? It says `ManyOccs`! But it's plain as a pikestaff that `x` is used at most once: * Either in the `A` branch, * or in the `B` or `C` branches via `j`. If instead we had inlined `j` we'd have {{{ let x = ... in join j y = x+y in case v of A -> x B -> x + 1 C -> x + 2 D -> 3 }}} and now it's all more obvious: `x`'s occurrence info should be `OneOcc { occ_one_br = False }`, not `ManyOccs`. Does this matter? Not a great deal, but there is a reason for having `OneOcc` with `occ_one_br = False`, and it seems a shame not to take advantage. One case in point is the definition of `SimplUtils.isExitJoinId {{{ isExitJoinId :: Var -> Bool isExitJoinId id = isJoinId id && isOneOcc (idOccInfo id) && occ_in_lam (idOccInfo id) }}} Something does not cease to be an exit-join-point if it is mentioned in multiple places as above. Another use for this info is `postInlineUnconditionally`. Could we improve this situation? I think it'd be quite easy. For non- recursive join points `j = rhs` * Gather occurrence info from the RHS * Bind `j` to its occurrence info * Unleash that occurrence info at each jump-site for `j`, just as if it had been inlined. See Trac #14152, comment:40. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1
by GHC 10 Feb '19

10 Feb '19

#15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC releases 8.2.1 through 8.4.3 exhibit various crashes when invoked with '-jn' where n > 1. GHCHQ's binary releases have this behavior, as well as GHCs I've cross-built on my own. In order to reproduce this issue there must be some parallelism in the module dependency graph; I've attached a test package for easily reproducing this. Use of deriving in the test modules isn't necessary to trigger this; it merely gives the compiler some work to do. The 'hscolour' package also triggers this issue reliably. To trigger the bad behavior, simply run: ghc --make -jn Main.hs -o test with n > 1 in the test-package. Running this repeatedly (removing .hi and .o files in between runs, of course), I've observed these outcomes with varying frequencies: - Segmentation fault. - Bus fault. - Compiler process sleeps indefinitely. - {{{ <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for aarch64-unknown-linux): Binary.UserData: no put_binding_name }}} - {{{ ghc: internal error: MUT_VAR_CLEAN object entered! (GHC version 8.4.3 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} - And most strangely: {{{ A.hs:3:1: error: • Kind signature on data type declaration has non-* return kind * • In the data declaration for ‘A’ | 3 | data A = A | ^^^^^^^^^^... }}} I have not noticed issues with any other concurrent Haskell programs on aarch64. I'm using the NVIDIA Jetson TX2 for these tests. I have not yet tried GHC 8.0.x, 8.6.x, or HEAD. I'm having trouble reproducing this in GDB; I'll report back when I've got that working. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270
by GHC 09 Feb '19

09 Feb '19

#12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 --------------------------------+--------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- This happened when building http-link-header. {{{ ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8 (GHC version 7.10.3 for powerpc_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Sometimes it segfaults instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15336: ./System/IO.hs accidentally overridden when running ghci
by GHC 08 Feb '19

08 Feb '19

#15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior. {{{ % mkdir System % touch System/IO.hs % ghci GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help <interactive>:1:19: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:43: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. <interactive>:1:60: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:99: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:123: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. <interactive>:1:140: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:179: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:203: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. <interactive>:1:220: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package
by GHC 08 Feb '19

08 Feb '19

#9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | 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: -------------------------------------+------------------------------------- I've observed a blowup in ghc memory usage when invoked with parallel build flags. to reproduce {{{ cabal get xmlhtml-0.2.3.2 cabal install xmlhtml-0.2.3.2 --only-dependencies cd xmlhtml-0.2.3.2 }}} then {{{ cabal clean ; cabal configure --ghc-options="-j4" ; time cabal build -j4 -v3 }}} will take quite a while and use > 1gb of ram whereas {{{ cabal clean ; cabal configure --ghc-options="-j1 ; time cabal build -j1 -v3 }}} will use < 150mb of ram. Based upon the output of cabal build -j4 -v3, it looks like the parallel build is spending a lottt more time in the simplifier passes. I'm not sure what changes between the parallel and sequential builds to change this. I'll try to dig into this more in a few days, but recording this problem now before i forget. (though of course any insights would be appreciated) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes
by GHC 08 Feb '19

08 Feb '19

#8635: GHC optimisation flag ignored when importing a local module with derived type classes ------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given Foo.hs and Bar.hs: {{{ module Foo where data Food = Food -- deriving Eq {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Bar where import Foo bar :: Int -> Bool bar x = x == 72 }}} If I run: {{{ ghc --make Bar -fforce-recomp }}} I get (snipped): {{{ Bar.bar = \ (x_afk :: GHC.Types.Int) -> case x_afk of _ { GHC.Types.I# x1_alo -> case x1_alo of _ { __DEFAULT -> GHC.Types.False; 72 -> GHC.Types.True } } }}} `bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get: {{{ Bar.bar1 = GHC.Types.I# 72 Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 }}} Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11822: Pattern match checker exceeded (2000000) iterations
by GHC 07 Feb '19

07 Feb '19

#11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- graphviz seems a nice benchmark (not too large, few dependencies) that highlights compiler performance problems on "trivial" source code (cf. https://hackage.haskell.org/package/graphviz-2999.18.0.2/docs/src /Data-GraphViz-Attributes-Complete.html#sameAttribute) Compilation of Compiling Data.GraphViz.Attributes.Colors.X11 and Data.GraphViz.Attributes.Values takes >= 1 second each, and the following happens: {{{ cabal install graphviz-2999.18.0.2 --allow-newer ... [17 of 31] Compiling Data.GraphViz.Attributes.Complete ( Data/GraphViz/Attributes/Complete.hs, dist/dist-sandbox- e6f2c124/build/Data/GraphViz/Attributes/Complete.o ) Data/GraphViz/Attributes/Complete.hs:1013:1: warning: Pattern match checker exceeded (2000000) iterations in an equation for ‘sameAttribute’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} I do welcome that ghc emits this warning - I expect you want its occurence to be reported as a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0
by GHC 07 Feb '19

07 Feb '19

#15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.5 libraries/base | 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: -------------------------------------+------------------------------------- {{{ _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all- packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package- id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' '-package-id rts-1.0' -i -i_build/stage1/libraries/base/build -i_build/stage1/libraries/base/build/autogen -ilibraries/base/. -Iincludes -I_build/generated -I_build/stage1/libraries/base/build -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/home/travis/build/snowleopard/hadrian/ghc/_build/stage1/lib/x86_64 -linux-ghc-8.5.20180617/rts-1.0/include -I_build/generated -optc- I_build/generated -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -optc- std=gnu99 -optc-fno-stack-protector -optP-std=gnu99 -odir _build/stage1/libraries/base/build -hidir _build/stage1/libraries/base/build -stubdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc- Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/base/GHC/Num.hs -o _build/stage1/libraries/base/build/GHC/Num.o -O0 -H64m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -ghcversion- file=/home/travis/build/snowleopard/hadrian/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe Exit code: 1 Stderr: ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180617 for x86_64-unknown-linux): Can't use Natural in base }}} We noticed this in hadrian land (in [https://github.com/snowleopard/hadrian/issues/499 this PR] and [https://github.com/snowleopard/hadrian/issues/629] and noticed that this happens: - with 8.4.2 as the boot compiler but not 8.2.2 - with integer-simple as the integer library - only with the quickest flavour (or more generally when we build GHC.Natural with -O0) Some optimisation seems critical to making any trace of `Natural` disappear, but this seems rather fragile. The code that throws the error got introduced in fe770c211631e7b4c9b0b1e88ef9b6046c6585ef. The full build log is available [https://travis- ci.org/snowleopard/hadrian/jobs/393259151#L4209 here], anchored to where the error appears. An example of hadrian command to reproduce the problem, assuming a configured build tree: `hadrian/build.sh --flavour=quickest --integer- simple -j4`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9