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

[GHC] #13600: surprising error message with bang pattern
by GHC 15 Oct '18

15 Oct '18

#13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the following code {{{ f3 :: [Int] -> IO Int f3 x = return (sum x) f4 :: [Int] -> IO Int f4 !x = return (sum x) }}} gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation
by GHC 15 Oct '18

15 Oct '18

#12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code (depends on singletons-2.2): {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators, KindSignatures, TypeInType, TypeFamilyDependencies, UndecidableInstances #-} module Bug where import Data.Kind (Type) import Data.Singletons.Prelude (Map, SndSym0) import GHC.TypeLits (Nat) data Payload = A | B newtype NewType a = NewType Int type NatList = [(Nat, Payload)] type StripNatList (natList :: NatList) = Map SndSym0 natList type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (StripNatList xs) }}} Why GHC is okay with injectivity annotation for `Family`: `r -> natList`? These two types: {{{#!hs type Foo = Family '[ '(0, 'A), '(1, 'B)] type Bar = Family '[ '(0, 'A), '(0, 'B)] }}} are obviously map to the same type: {{{#!hs *Bug Data.Singletons.Prelude> :kind! Foo Foo :: * = NewType ('A :$$$ '['B]) *Bug Data.Singletons.Prelude> :kind! Bar Bar :: * = NewType ('A :$$$ '['B]) }}} ---- If inline `StripNatList` inside `Family` definition: {{{#!hs type family Family (natList :: NatList) = (r :: Type) | r -> natList where Family '[] = () Family xs = NewType (Map SndSym0 xs) }}} or change `StripNatList` definition to type family: {{{#!hs type family StripNatList (natList :: NatList) where StripNatList '[] = '[] StripNatList ('(n, x) ': xs) = x ': StripNatList xs }}} compilation expectedly fails with `Type family equation violates injectivity annotation.` ---- Moreover, if I remove `NewType` from `Family` and change result kind: {{{#!hs type family Family (natList :: NatList) = (r :: [Payload]) | r -> natList where Family xs = StripNatList xs }}} it fails with correct error regardless of `StripNatList` definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6