January 2017 - ghc-tickets

[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] #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

[GHC] #10053: problem in ghci calling main after loading compiled code
by GHC 06 Apr '17

06 Apr '17

#10053: problem in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load rsa Ok, modules loaded: Main. Prelude Main> :show modules Main ( rsa.hs, rsa.o ) Prelude Main> main Too late for parseStaticFlags: call it before runGhc or runGhcT *** Exception: ExitFailure 1 Prelude Main> note, there is no failure if I load interpreted code -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #13000: minor doc bug about list fusion in GHC user's guide
by GHC 06 Apr '17

06 Apr '17

#13000: minor doc bug about list fusion in GHC user's guide -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First, the Users Guide (8.0.1.20161117) in section 10.32.6,List fusion, should mention length as a good consumer. Secondly, it says: "If you want to write your own good consumers or producers, look at the Prelude definitions of the above functions to see how to do so." However if you go to https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html and look at the source code for length you end up at https://hackage.haskell.org/package/base-4.9.0.0/docs/src/Data.Foldable.htm… which is not a good consumer. I think the User's Guide should be changed to replace "Prelude" with "https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.List.html". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11544: SCC call-stack from `error` missing call-sites
by GHC 05 Apr '17

05 Apr '17

#11544: SCC call-stack from `error` missing call-sites -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- For some reason the `-prof` stack that `error` attaches only includes the top-level CAF. This is with the default build settings (which I believe are the release settings?) {{{ $ cat Foo.hs main = print (foo [1]) foo xs = tail (tail xs) $ ./inplace/bin/ghc-stage2 --make -prof -fprof-auto-calls Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) [flags changed] Linking Foo ... $ ./Foo Foo: Prelude.tail: empty list CallStack (from -prof): GHC.List.CAF (<entire-module>) }}} I would expect to at least see the call-site of `foo` (if not also `tail`) in the stack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11425: The GHC API doesn't provide a good hscTarget option for tooling
by GHC 05 Apr '17

05 Apr '17

#11425: The GHC API doesn't provide a good hscTarget option for tooling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: high | Milestone: 8.2.1 Component: GHC API | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tools like ghc-mod typically just want `TypecheckedModule`s. Sadly, the GHC API currently doesn't provide a good way to get at these in all cases (see this [https://github.com/DanielG/ghc-mod/issues/205|ghc-mod ticket]). Each of the options we offer are cursed with their own limitations (largely quoting from the ghc-mod ticket), == HscNothing == At first glance this looks like what you would want. But... * Pros * Doesn't generate code of any sort and is therefore rather lightweight * Cons * It lacks support for Template Haskell * Has trouble with `foreign export`s * [https://github.com/DanielG/ghc-mod/pull/145|Fails} to issue pattern match checker warnings == HscInterpreted == Okay, so `HscNothing` doesn't work. Maybe `HscInterpreted` is better? * Pros * Supports Template Haskell * Cons * Can't deal with unboxed tuples (#1257) * Slower as we need to produce unnecessary bytecode * Large memory footprint * Also can't deal with `foreign export`s == HscAsm == * Pros * Supports all compilable code * Cons * Slow * Produces `.o` files This is quite unfortunate. It seems like we need something in between `HscNothing` and `HscInterpreted` which is willing to use the interpreter to evaluate Template Haskell splices when necessary, but doesn't produce bytecode. Unfortunately it's unclear what to do about `foreign export` (but arguably most tools would be fine with some approximate representation). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7