July 2016 - ghc-tickets

[GHC] #8585: Loopification should omit stack check
by GHC 11 Apr '17

11 Apr '17

#8585: Loopification should omit stack check ------------------------------+-------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When we optimize a self-recursive tail call using loopification we don't need to perform a stack check in every loop. This is because a tail recursive function uses constant amount of stack. We should therefore place the loop header after the stack check, but before the heap check (because heap may grow in every call). parcs proposed a patch [https://ghc.haskell.org/trac/ghc/ticket/8275#comment:34 here]. We just need to make sure why it works and add some documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm
by GHC 11 Apr '17

11 Apr '17

#8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm ------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello, on SPARC and I also guess on PPC it's possible to get following line in optimized Cmm code: {{{ I64[BaseReg + 784] = I64[BaseReg + 784]; }}} this line is then translated by NCG wasting 5 isns on SPARC at least. Don't know PPC. I'm not sure if this is possible to duplicate this on i386 due to fewer regs. Generally speaking you need to have 32bit target with more regs available. Interesting fact is that such line is not presented in non-optimized Cmm, but is presented in optimized one. Both optimized and non-optimized Cmms attached. Both get from compiling T7507 testcase by stage1 compiler on SPARC: {{{ /home/karel/vcs/ghc-src/ghc-sparc-reg_ncg/inplace/bin/ghc-stage1 -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7507.hs -O -ddump-opt-cmm > T7507.opt-cmm- sparc-reg-ncg }}} Of course non-opt Cmm is got by -ddump-cmm instead of -ddump-opt-cmm. If you need more simplified testcase, then following code is usable too: {{{ module Main where import Data.Int main = print ( ( 2 ^ 6 ) :: Int64 ) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8887: Double double assignment in optimized Cmm on SPARC
by GHC 11 Apr '17

11 Apr '17

#8887: Double double assignment in optimized Cmm on SPARC ----------------------------+-------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Runtime performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------------------------- Hello, while reading ffi003 asm/opt-cmm for fixing this on SPARC I've noticed this code, this is optimized Cmm dump: {{{ 112 c1or: 113 _s1nw::F64 = F64[_s1nv::P32 + 3]; 114 _c1oj::I32 = sin; 115 _c1ok::F64 = _s1nw::F64; }}} this assignment to _s1nw::F64 looks useless as we may assign directly to _c1ok::F64, may we not? Both optimized and non-optimized Cmms attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8887> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9159: cmm case, binary search instead of jump table
by GHC 11 Apr '17

11 Apr '17

#9159: cmm case, binary search instead of jump table ------------------------------+-------------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I'm not sure if this is qualifies as a bug or feature request. For case expressions where the scrutinee is Int#,or Int, or probably anything else numerical, GHC generates binary search, where a jump table could easily be used instead. The functions toChunk1# and toChunk2# yield suboptimal code. I found a satisfactory workaround, toChunk3# uses Enum and it is fine. For the attached code it probably does not matter much, but I have 65 cases in my real code, trying to implement a variant of ByteString, which will have the lowest possible storage overhead (just the info table pointer == one word) for lengths up to 64 bytes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

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