March 2018 - ghc-tickets

[GHC] #14872: Hex Literals in GHC Core
by GHC 19 Mar '18

19 Mar '18

#14872: Hex Literals in GHC Core -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Sometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this: {{{ detectNull :: Word -> Word detectNull x = (x - repeatHexZeroOne) .&. complement x .&. repeatHexEightZero detectArtifact :: Word -> Word -> Word detectArtifact x artifact = detectNull (applyArtifact x artifact) applyArtifact :: Word -> Word -> Word applyArtifact = xor repeatHexZeroOne :: Word repeatHexZeroOne = div maxBound 255 repeatHexEightZero :: Word repeatHexEightZero = 128 * (div maxBound 255 :: Word) }}} Once everything gets unboxed and constant-folding happens, in GHC core, the places where I used `repeatHexZeroOne` show `72340172838076673##` (on a 64-bit machine). This is accurate, but it would be nice I could give a flag to make it show `0x0101010101010101##` instead. This would make it easier for me to confirm that the arithmetic I used to generate a bit pattern actually generated what I thought it did. Admittedly, we'd probably want leading zeroes to get chopped off so that small integer literals didn't show up with 15 zeroes in front of them. So, realistically, it might show up as `0x101010101010101##`. Or maybe it could always to padded with leading zeroes until the length was a power of two. Anyway, not important, but I thought it would be nice to have. Possible flag name: `-ddump-hex-literals`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14881: Consistent labeling of redundant, qualified imports
by GHC 19 Mar '18

19 Mar '18

#14881: Consistent labeling of redundant, qualified imports -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ import Data.Map as M (Map, adjust, lookup, fromList) foo :: Map Int Int foo = fromList [] }}} GHC helpfully suggests: {{{ Bug.hs:3:1: warning: [-Wunused-imports] The import of `adjust, M.lookup' from module `Data.Map' is redundant | 3 | import Data.Map as M (Map, adjust, lookup, fromList) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} However, this message can be improved. Notice that in the line "The import of ...", `adjust` is *not* qualified, while `lookup` *is* qualified. It would be better if this was consistent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14923: Recompilation avoidance fails after a LANGUAGE change
by GHC 19 Mar '18

19 Mar '18

#14923: Recompilation avoidance fails after a LANGUAGE change -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It looks like the recompilation checker can be confused when a LANGUAGE pragma is added or removed. The following shell script demonstrates the issue: {{{ #!/bin/sh cat >Foo.hs <<END {-# LANGUAGE UndecidableInstances #-} module Foo where END rm -f Foo.hi Foo.o ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag sed -i 's/^{-#/--&/' Foo.hs # comment out the pragma ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag }}} I get this output: {{{ % ./bug.sh flag hash: b1ada48735eec2ef16d5070887aa7f10 flag hash: b1ada48735eec2ef16d5070887aa7f10 flag hash: e7b294090e04f1a84f0bfc9b8cc49322 compilation IS NOT required flag hash: e7b294090e04f1a84f0bfc9b8cc49322 }}} In the third invocation to GHC, I expect the recompilation checker to detect that compilation is not required, because nothing has changed since the second invocation. Also it seems suspicious that the flag hash changes beteen the second run and the third run. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 19 Mar '18

19 Mar '18

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"2918abf75594001deed51ee252a05b146f844489/ghc" 2918abf7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2918abf75594001deed51ee252a05b146f844489" rts: Add --internal-counters RTS flag and several counters The existing internal counters: * gc_alloc_block_sync * whitehole_spin * gen[g].sync * gen[1].sync are now not shown in the -s report unless --internal-counters is also passed. If --internal-counters is passed we now show the counters above, reformatted, as well as several other counters. In particular, we now count the yieldThread() calls that SpinLocks do as well as their spins. The added counters are: * gc_spin (spin and yield) * mut_spin (spin and yield) * whitehole_threadPaused (spin only) * whitehole_executeMessage (spin only) * whitehole_lockClosure (spin only) * waitForGcThreadsd (spin and yield) As well as the following, which are not SpinLock-like things: * any_work * do_work * scav_find_work See the Note for descriptions of what these counters are. We add busy_wait_nops in these loops along with the counter increment where it was absent. Old internal counters output: ``` gc_alloc_block_sync: 0 whitehole_gc_spin: 0 gen[0].sync: 0 gen[1].sync: 0 ``` New internal counters output: ``` Internal Counters: Spins Yields gc_alloc_block_sync 323 0 gc_spin 9016713 752 mut_spin 57360944 47716 whitehole_gc 0 n/a whitehole_threadPaused 0 n/a whitehole_executeMessage 0 n/a whitehole_lockClosure 0 0 waitForGcThreads 2 415 gen[0].sync 6 0 gen[1].sync 1 0 any_work 2017 no_work 2014 scav_find_work 1004 ``` Test Plan: ./validate Check it builds with #define PROF_SPIN removed from includes/rts/Config.h Reviewers: bgamari, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #3553, #9221 Differential Revision: https://phabricator.haskell.org/D4302 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14779: Compiling with -g fails -lint-core checks
by GHC 19 Mar '18

19 Mar '18

#14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14122, #14123, | #8472, #14406 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the attached file produces: {{{ $ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of str_s2UI :: Addr#] The type of this binder is unlifted: str_s2UI Binder's type: Addr# *** Offending Program *** ... str_s2UI :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}] str_s2UI = src<Data.Fixed.hs:78:31-39> "MkFixed"# str_a2j4 :: String [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] str_a2j4 = src<Data.Fixed.hs:78:31-39> unpackCString# str_s2UI ... }}} This came up when I wanted to compile GHC HEAD with `-g`. There are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example. I'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope. My HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #14868: -O -g breaks string literals
by GHC 19 Mar '18

19 Mar '18

#14868: -O -g breaks string literals -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `foo.hs`: {{{#!hs main = print (4, "foo") }}} Compile it and run it like: {{{ % ghc-stage2 -O -g foo.hs % ./foo (4,"\CANq@") }}} Note that the content of the string literal is broken, although the length is preserved. With `-dcore-lint`, the following error is produced: {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of ww2_s3hG :: Addr#] Recursive or top-level binder has strict demand info: ww2_s3hG Binder's demand info: <L,U> }}} The offending binding is: {{{#!hs ww2_s3hG :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] ww2_s3hG = src<foo.hs:1:18-22> "foo"# }}} Happens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 19 Mar '18

19 Mar '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by carter): Ben: what are your current thoughts about how to handle supporting different microarchitectures? 1) Allow generating the instructions but require the application to do cpu detection to avoid bad instructions ? (I’d be fine with that ) Or 2) add micro architecture logic to ghc compilation and have a fall back path? Or 3) some mix of both supported? I’d think near term 1 would be simpler to get working and 3 is what we want to love to -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 19 Mar '18

19 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"5a1ad231fc871f27f2811ae46285a79573d8dfae/ghc" 5a1ad231/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5a1ad231fc871f27f2811ae46285a79573d8dfae" Update test for #5129: Make sure it runs with --fast validate with correct optimisation settings (-O1 or above) so that it actually tests the bug. Because the bug is in the simplifier running it with -O0 doesn't test it. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits`
by GHC 19 Mar '18

19 Mar '18

#10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: | Version: 7.10.2 libraries/base | Keywords: TypeLits | Operating System: Unknown/Multiple Natural | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When the numeric type-literals were implement via `GHC.TypeLits` there was no `Natural` type in `base` yet. But since GHC 7.10 we finally have `Natural` available in base! Specifically, the following 3 type-signatures in `GHC.TypeLits` cpmtaom `Integer` that ought rather be `Natural`s: {{{#!hs someNatVal :: Integer -> Maybe SomeNat natVal :: forall n proxy. KnownNat n => proxy n -> Integer natVal' :: forall n. KnownNat n => Proxy# n -> Integer }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14895: STG CSE makes dead binders undead
by GHC 19 Mar '18

19 Mar '18

#14895: STG CSE makes dead binders undead -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs go :: (a -> b) -> Either String a -> Either String b go f (Right a) = Right (f a) go _ (Left e) = Left e }}} GHC with `-O2` converts it into the following STG: {{{#!hs TestUndead.go :: forall a b. (a -> b) -> Data.Either.Either GHC.Base.String a -> Data.Either.Either GHC.Base.String b [GblId, Arity=2, Caf=NoCafRefs, Str=<L,1*C1(U)><S,1*U>, Unf=OtherCon []] = \r [f_s17n ds_s17o] case ds_s17o of { Data.Either.Left e_s17q [Occ=Once] -> wild_s17p; Data.Either.Right a1_s17r [Occ=Once] -> let { sat_s17s [Occ=Once] :: b_aVN [LclId] = \u [] f_s17n a1_s17r; } in Data.Either.Right [sat_s17s]; }; }}} Notice that the dead binder `wild_s17p` is now alive (in the first alternative) but it isn't shown in `case ds_s17o of {` because the pretty- printer still assumes it is dead. I think that in `stgCseExpr .. (StgCase ...)` (simplStg/StgCse.hs) we should check if the new binder is alive in the new alternatives, just like we do in `coreToStgExpr (Case ...)` (stgSyn/CoreToStg.hs), and use `setIdOccInfo (ManyOccs NoTailCallInfo)` on the new binder if necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14895> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4