March 2017 - ghc-tickets

[GHC] #8505: Arrows example error
by GHC 11 Apr '17

11 Apr '17

#8505: Arrows example error ------------------------------------+-------------------------------------- Reporter: pdfrod | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- In the section '''7.15.2. Conditional commands''' of the User's Guide (http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/arrow- notation.html#idp49515792) it is stated that: {{{ proc (x,y) -> if f x y then g -< x+1 else h -< y+2 }}} is translated to: {{{ arr (\ (x,y) -> if f x y then Left x else Right y) >>> (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g) }}} But this translation doesn't seem correct, because the arrows ''g'' and ''h'' are not being used as in the original code (''h'' doesn't appear at all in the translation). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10582: Tiny bug in lexer around lexing banana brackets
by GHC 11 Apr '17

11 Apr '17

#10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE Arrows #-} (|:) :: Int -> Int -> Int (|:) = (+) }}} I get {{{ /Users/rae/temp/Bug.hs:3:3: parse error on input ‘:’ }}} Trying this with other operators, like `(|+)`, works fine. The problem is that `notFollowedBySymbol` in Lexer.x is slightly wrong. I will fix in ongoing (mostly unrelated) work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13371: instance selection too eager
by GHC 10 Apr '17

10 Apr '17

#13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | 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 see a regression in 8.0.2: the `g_f'` definition is rejected. The error goes away if I do one of: * -XNoMonoLocalBinds * -XNoPolyKinds * pasting the inferred type of `g_f` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12004: Windows unexpected failures
by GHC 10 Apr '17

10 Apr '17

#12004: Windows unexpected failures ----------------------------------------+--------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Not sure if these are known or not, sorry if they are. In the 8.0 branch, aab92412cf4cb77d988d36fb013018695c271ccd: {{{ OVERALL SUMMARY for test run started at Mon May 2 11:38:07 2016 PDT 0:40:00 spent to go through 5076 total tests, which gave rise to 14703 test cases, of which 9620 were skipped 73 had missing libraries 4857 expected passes 141 expected failures 0 caused framework failures 0 unexpected passes 12 unexpected failures 0 unexpected stat failures Unexpected failures: ghci.debugger/scripts break011 [bad stdout] (ghci) ghci/prog003 prog003 [bad exit code] (ghci) ghci/scripts T5566 [bad exit code] (ghci) rts testmblockalloc [bad exit code] (normal) rts/T11223 T11223_link_order_a_b_2_fail [bad exit code] (normal) rts/T11223 T11223_link_order_a_b_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_2_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_succeed [bad exit code] (normal) rts/T11223 T11223_simple_duplicate_lib [bad exit code] (normal) rts/T11223 T11223_simple_link [bad exit code] (normal) rts/T11223 T11223_simple_link_lib [bad exit code] (normal) rts/T11223 T11223_simple_unused_duplicate_lib [bad exit code] (normal) }}} In HEAD, 36d29f7ce332a2b1fbc36de831b0eef7a6405555: {{{ OVERALL SUMMARY for test run started at Mon May 2 14:07:48 2016 PDT 0:42:17 spent to go through 5112 total tests, which gave rise to 14803 test cases, of which 9680 were skipped 72 had missing libraries 4903 expected passes 140 expected failures 0 caused framework failures 0 unexpected passes 8 unexpected failures 0 unexpected stat failures Unexpected failures: ghci.debugger/scripts break011 [bad stdout] (ghci) ghci/prog003 prog003 [bad exit code] (ghci) partial-sigs/should_compile PatBind [exit code non-0] (normal) plugins plugins01 [bad exit code] (normal) rts T7037 [bad stdout] (normal) rts T9405 [bad exit code] (normal) rts testmblockalloc [bad exit code] (normal) rts/T11223 T11223_simple_duplicate_lib [bad exit code] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10613: Mechanism for checking that we only enter single-entry thunks once
by GHC 10 Apr '17

10 Apr '17

#10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- During this week's GHC call it came up that it would be nice to have a linting mechanism for verifying that we only enter single-entry thunks once, as currently this invariant appears to be completely unchecked. Currently we do not record whether a thunk is intended to be single-entry when we emit its code. Moreover, I don't believe there is any room for this left in the info table to record this fact. There are two ways I can think of accomodating this, * stealing a bit from the thunk type field * add a flags field to `StgDebugInfo` such that the lint requires the `debug` way As far as implementing the check itself, I think it should be rather straightforward. When we enter a thunk we simply want to check whether it is single-entry. If it is then we replace it with a special type of `BLACKHOLE`-like thunk which crashes the program (or merely emits a warning) on entry. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #8816: Make SPARC registerised again.
by GHC 10 Apr '17

10 Apr '17

#8816: Make SPARC registerised again. -----------------------------------+--------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- It looks like recent GHC switched to unregisterised build on SPARC by default. This is kind of regression with the past GHCs where registerised builds were supported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13479: Core Lint issues during slowtest
by GHC 09 Apr '17

09 Apr '17

#13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm am seeing Core Lint failurse from the `T5626` test, {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of go_s54c :: [Int] -> (Int, Int, Int, Int)] idArity 2 exceeds typeArity 1: go_s54c }}} The relevant bits of the program are, {{{#!hs Rec { go_s54c [Occ=LoopBreaker] :: [Int] -> (Int, Int, Int, Int) [LclId, Arity=2, CallArity=2, Str=<B,U>b, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=NEVER}] go_s54c = \ (ds_X35o :: [Int]) -> case ds_X35o of { [] -> case lvl_s4Vm of wild_00 { }; : y_a34y [Dmd=<B,A>] ys_a34z [Dmd=<B,U>] -> go_s54c ys_a34z } end Rec } lvl_s54d :: (Int, Int, Int, Int) [LclId, Arity=1, Str=x, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=NEVER}] lvl_s54d = go_s54c ([] @ Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12793: Performs unaligned access on SPARC64
by GHC 09 Apr '17

09 Apr '17

#12793: Performs unaligned access on SPARC64 --------------------------------+---------------------------------------- Reporter: jrtc27 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: sparc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- (Filed under Architecture: sparc, since there's no sparc64 in the dropdown...) Trying to build GHC on sparc64 currently crashes with a SIGBUS (unaligned access). This is because sparc64 uses the C backend (only 32-bit sparc has native code gen), but is unaware that it can't perform unaligned accesses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12396: Panic when specializing in another module
by GHC 08 Apr '17

08 Apr '17

#12396: Panic when specializing in another module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the attached example (which requires `criterion` and `deepseq`), when compiled with `ghc -O2 -funfolding-use-threshold1000 Main.hs`, I get the following error on `Main.hs`: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): StgCmmEnv: variable not found $d(%,%)_aaTF local binds for: $trModule $sfool $trModule1 $trModule2 $wlvl_rgY8 lvl_rgY9 lvl1_rgYa lvl3_rgYc lvl4_rgYd lvl5_rgYe lvl6_rgYf lvl7_rgYg lvl8_rgYh lvl9_rgYi lvl10_rgYj lvl11_rgYk lvl12_rgYl lvl13_rgYm lvl14_rgYn lvl15_rgYo lvl16_rgYp lvl17_rgYq lvl18_rgYr lvl19_rgYs lvl20_rgYt lvl21_rgYu lvl22_rgYv lvl23_rgYw lvl24_rgYx lvl25_rgYy lvl26_rgYz lvl27_rgYA lvl28_rgYB lvl29_rgYC lvl30_rgYD lvl31_rgYE lvl32_rgYF lvl33_rgYG lvl34_rgYH lvl35_rgYI lvl36_rgYJ lvl37_rgYK lvl38_rgYL lvl39_rgYM lvl40_rgYN lvl41_rgYO lvl42_rgYP lvl43_rgYQ lvl44_rgYR lvl45_rgYS lvl46_rgYT lvl47_rgYU lvl48_rgYV lvl49_rgYW lvl50_rgYX lvl51_rgYY lvl52_rgYZ lvl53_rgZ0 lvl54_rgZ1 lvl55_rgZ2 lvl56_rgZ3 lvl57_rgZ4 lvl58_rgZ5 lvl59_rgZ6 lvl60_rgZ7 lvl61_rgZ8 lvl62_rgZ9 lvl63_rgZa lvl64_rgZb lvl65_rgZc lvl66_rgZd ww1_rgZe ww2_rgZf ww3_rgZg ww4_rgZh pinfo_rgZi pinfo1_rgZj pinfo2_rgZk pinfo3_rgZl lvl67_rgZm lvl68_rgZn lvl69_rgZo $wgo12_rgZp eta_sh1k wild_sh1l v_sh1m sat_sh1n }}} I initially found this bug when I added a `SPECIALIZE` pragma for `fool` in `Main.hs`. However, I need `funfolding-use-threshold1000` and the constraint synonym `UCRTElt` in `Foo.hs` to trigger the bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13135: Typechecker: the 'impossible' happened
by GHC 06 Apr '17

06 Apr '17

#13135: Typechecker: the 'impossible' happened -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | 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: -------------------------------------+------------------------------------- May be something to do with type family dependencies? Unclear - but I've attached a reduced source. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9