September 2018 - ghc-tickets

[GHC] #15258: Implement CMOV support.
by GHC 20 Oct '18

20 Oct '18

#15258: Implement CMOV support. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14830: Use test instead of cmp for comparison against zero.
by GHC 20 Oct '18

20 Oct '18

#14830: Use test instead of cmp for comparison against zero. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: (NCG) | 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 comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86. However using test leads to slightly smaller code. (Saves a byte per comparison). A good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen starting with how CmmCondBranch is compiled to Instructions. From there it should be not too hard to track down the required changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin
by GHC 19 Oct '18

19 Oct '18

#15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple SourcePlugins, plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs. {{{ WARNING in hptSomeThingsBelowUs missing module CoercePlugin Probable cause: out-of-date interface files }}} I don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15349: fixST is a bit wrong
by GHC 18 Oct '18

18 Oct '18

#15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.5 Libraries | 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: -------------------------------------+------------------------------------- Lazy blackholing lets some `ST` calculations complete that shouldn't. {{{#!hs import Control.Monad.ST.Strict import Control.Monad.Fix import Data.STRef foo :: ST s Int foo = do ref <- newSTRef True mfix $ \res -> do x <- readSTRef ref if x then do writeSTRef ref False return $! (res + 5) else return 10 main = print $ runST foo }}} When this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`. Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440
by GHC 18 Oct '18

18 Oct '18

#15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package | Version: 8.4.3 system | Keywords: cabal, cpphs, | Operating System: MacOS X strange closure | Type of failure: Building GHC Architecture: x86 | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attempting to install Agda via Cabal fails. I've installed cpphs through Cabal and {{{~/Library/Haskell/bin}}} is in my path. {{{~/.cabal/config}}} is default, but in {{{/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings}}} I have changed only {{{("C compiler supports -no- pie","NO")}}} (from "YES") because that was giving me errors earlier. The log states: "Please report this as a GHC bug..." so here I am :] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'
by GHC 18 Oct '18

18 Oct '18

#15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ % cat Nopie.hs module Nopie where main :: IO () main = putStrLn "hi" % ghc -fforce-recomp -c -fhpc Nopie.hs clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] }}} This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output. Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15680: Flag for printing absolute paths in diagnostics
by GHC 18 Oct '18

18 Oct '18

#15680: Flag for printing absolute paths in diagnostics -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 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: -------------------------------------+------------------------------------- Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it. This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations. In particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output. [https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c… Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.] I can personally report that this makes the development process a lot more pleasant! I think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding. I had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15692: GHC panic from pattern synonyms + deferred type errors
by GHC 17 Oct '18

17 Oct '18

#15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-} {-# Options_GHC -dcore-lint -fdefer-type-errors #-} import Data.Kind data Ctx :: Type -> Type where E :: Ctx(Type) (:&:) :: a -> Ctx(as) -> Ctx(a -> as) data ApplyT (k::Type) :: k -> Ctx(k) -> Type where AO :: a -> ApplyT(Type) a E AS :: ApplyT(ks) (f a) ctx -> ApplyT(k -> ks) f (a:&:ctx) pattern ASSO = AS (AS (AO False)) }}} {{{ $ ghci -ignore-dot-ghci 463.hs hs/463.hs:16:27: warning: [-Wdeferred-type-errors] • Couldn't match type ‘a a1 a2’ with ‘Bool’ Expected type: a3 Actual type: Bool • In the pattern: False In the pattern: AO False In the pattern: AS (AO False) | 16 | pattern ASSO = AS (AS (AO False)) | ^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): urk! lookup local fingerprint $mASSO [iESflb :-> ($trModule, 1ca40dc83a9c879effdb760462cc9a2d), iESgKD :-> ($tc'E, 79f67a27a14dc1bb6eecb39e4b061e2c), iESgKF :-> ($tc':&:, 24793c0c1652ffcf92e04f47d38fa075), iESgKH :-> ($tcCtx, a3f9358cbfe161bf59e75500d70ce0ae), iESgKI :-> ($tc'AO, 72111d1891cb082e989c20a2191a8b4b), iESgKK :-> ($tc'AS, ff019c04c400d5fbdd46ff8a816d4913), iESgKM :-> ($tcApplyT, cbfe28374b4115925c7213e6330ab115)] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:524:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11307: Regresssion: parsing type operators
by GHC 17 Oct '18

17 Oct '18

#11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- GHC 7.10.3 will parse (but not type-check) the following {{{#!hs {-# LANGUAGE TypeOperators #-} type family (r1 :++: r2); infixr 5 :++: type instance r :++: Nil = r type instance r1 :++: r2 :> a = (r1 :++: r2) :> a }}} Current master (c7830bdb14e0a85a78617314156d101155fdf7aa) fails with {{{#!hs /tmp/Foo.hs:5:15: error: Malformed head of type or class declaration: r1 :++: r2 :> a }}} @simonpj comment on ghc-devs mailing list > `| type instance r1 :++: r2 :> a = (r1 :++: r2) :> a` > > What do you expect this to mean? I suppose you could hope that GHC will > unravel the fixity of :++: and :>, to determine whether you are giving an > instance for :++: or for :>? > > That sounds reasonable, but it's not trivial. > > Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and > it looks like this: > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_tycon :: Located name > , tfe_pats :: pats > , tfe_rhs :: LHsType name } > }}} > > So we've already decided (in the parser) what the type-function name is. > But we can't do that in this case, because the parser doesn't understand > fixity. > > To deal with this we'd need to change to > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_lhs :: LHSType name > , tfe_rhs :: LHsType name } > }}} > > so that the LHS was just a type. Now the renamer can re-jiggle its > fixities in the usual way, and only in the type checker will we need to > decide exactly which type it's an instance of. Easy! > > This might be a good change to make! It's a bit like in ClsInstDecl, you'll > see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed > into which class it is. > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15278: Add -Werror=compat, enable it in the testsuite
by GHC 15 Oct '18

15 Oct '18

#15278: Add -Werror=compat, enable it in the testsuite -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- = Proposed change Add a flag `-Werror=compat` to GHC which would have the effect of `-Werror=x -Werror=y ...` where `x, y, ...` are warnings from `minusWcompatOpts`. Enable `-Wcompat -Werror=compat` in the testsuite. = Motivation 1. `-Werror=compat` would be a convenient shorthand to ensure forwards- compatibility of code. I can imagine Haskell libs enabling it on their CI. 2. Enabling `-Wcompat -Werror=compat` in the testsuite would allow us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards-compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates. The idea came up during my work on Phab:D4834 which defines a new warning and adds it to `-Wcompat`. Ryan Scott raised the following concern: > There are likely many tests in the testsuite that will now fail due to this change—I'm unclear if you're intending to fix them by explicitly quantifying their kind variables, or leaving the new error message as-is. My intention was to update the test cases, but it turned out that I couldn't even locate these test cases without `make EXTRA_HC_OPTS="-fwarn- implicit-kind-vars -Werror=implicit-kind-vars"`. And even if I updated the testsuite, nothing would prevent new test cases that are not forwards- compatible, because the warning isn't enabled by default (and without `-Werror=compat`, enabling `-Wcompat` would not cause test failures in all circumstances). = Implementation plan 1. Add new flags: `-Werror=compat`, `-Wno-error=compat`, `-Wwarn=compat`. 2. Document these flags in the User's Guide. 3. Enable `-Wcompat -Werror=compat` in the testsuite by default and fix all tests that break. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4