- ghc-tickets - Haskell.org

[GHC] #11008: GND with Type Families
by GHC 07 Nov '18

07 Nov '18

#11008: GND with Type Families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- In the following code: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances #-} class C r type family F r newtype Foo r = Foo r instance (C (F r), Eq r) => Eq (Foo r) newtype Bar r = Bar (Foo r) deriving (Eq) }}} GHC produces the error {{{ No instance for (C (F r)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq (Bar r)) }}} If I enable `StandaloneDeriving`, I am able to derive the instance: `deriving instance (Eq (Foo r)) => Eq (Bar r)` [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.ht… #newtype-deriving The docs] indicate that this is exactly the instance that should be generated by GND for `newtype T v1..vn = MkT (t vk+1..vn) deriving (C t1..tj)`, where my code uses the following parameters: {{{ T = Bar v1 = r n = 1 MkT = Bar t = Foo r k= 1 C = Eq j = 0 }}} and all of the conditions enumerated in the docs seem to be met. Furthermore, `Bar` seems to fit squarely into the format of `data T1` in section 7.5.1 of the same documentation, which indicates it should not need `StandaloneDeriving`. It seems that the type family constraint on the `Eq` instance for `Foo` is causing the problem, but it's not clear why I'm forced to write a standalone instance that is identical to the one that should be generated by GND. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12620: Allow the user to prevent floating and CSE
by GHC 07 Nov '18

07 Nov '18

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This is a write-up of a rough idea that Andres Löw and me had at ICFP 2016 in order to address some Real World problems Andres noticed and that are currently hard to avoid. The goal is to give the user more control about expressions that the compiler would like to float out (or CSE), but the programmer knows better. Example (assume no list fusion exists): {{{ enum xs = zip [1..] xs }}} This leads to a horrible space leak, as GHC will float out `[1..]` to the top. Our idea is to have a magic function `nofloat :: a -> a` (magic in the same sense as `inline` and `lazy`) that the programmer would use here: {{{ enum xs = zip (nofloat [1..]) xs }}} With these effects: * Sub expressions are not floated out of a `nofloat`. * An expression of the form `nofloat e` would not be floated beyond the innermost enclosing lambda. * Two expressions of the form `nofloat e` would not be commoned up by CSE. This way, unwanted sharing is prevented. In contrast to a hypothetical `veryCheap` function, it does ''not'' mean that the compiler should float it into lambda (no unwanted duplication either). Two open questions (among many others, I am sure:) * Likely, rule matching should look through `nofloat`. At least in this example (and similar ones like `map (nofloat [1..])`, the rules in question will avoid the spaceleaks). * Possibly, nothing should be floated (inlined) ''into'' a `nofloat`. Rationale: Assume the library is changed so that {{{ [n..] = nofloat (realEnumFrom n) {-# INLINE [n..] #-} }}} Then `zip [fib 1000..]` would be rewritten by the inliner to `zip (let x = fib 1000 in (nofloat [x..]))`. Moving the `fib 1000` into the `nofloat` would change the behaviour in a possibly surprising way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #13080: Constant values are not floated out of the loop
by GHC 07 Nov '18

07 Nov '18

#13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- See this stackoverflow post: http://stackoverflow.com/a/41521876/110081 Basically, the following program leaks memory on ghc 7.10.3 and ghc 8.0.1. {{{#!hs import Control.Monad (forever) main :: IO () main = worker {-# NOINLINE worker #-} worker :: (Monad m) => m () worker = forever $ poll () poll :: (Monad m) => () -> m a poll action = do return () poll action }}} Could ghc do better there? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #15805: Bug in anyRewritableTyVar
by GHC 06 Nov '18

06 Nov '18

#15805: Bug in anyRewritableTyVar -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14363 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current implementation of `TcType.anyRewritableTyVar` has one wrong case: {{{#!hs go_tc ReprEq bvs tc tys = foldr ((&&) . go_arg bvs) False $ (tyConRolesRepresentational tc `zip` tys) }}} Here `foldr` uses `&&` in the function and a `False` as the initial value, which causes this case to always return `False` no matter what the inputs are. This bug is introduced in [changeset:"3acd6164fea6d4d5d87521a291455a18c9c9a8ee/ghc" 3acd616/ghc], which is for fixing #14363. The correct implementation (I think) should use `||` instead of `&&`: {{{#!hs go_tc ReprEq bvs tc tys = foldr ((||) . go_arg bvs) False $ (tyConRolesRepresentational tc `zip` tys) -- or just go_tc ReprEq bvs tc tys = any (go_arg bvs) (tyConRolesRepresentational tc `zip` tys) }}} We presume that there might be some program which loops because of this bug. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15275: AArch64 validation fails with many invalid relocations
by GHC 06 Nov '18

06 Nov '18

#15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | 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: -------------------------------------+------------------------------------- Test ways requiring the RTS linker (e.g. `ext-interp`) are failing due to the `assert(isInt64(32, addend));` assertion in the `COMPAT_R_AARCH64_ADR_PREL_PG_HI21` of `encodeAddendAarch64`. One such relocation is, {{{ RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 000000000000001c R_AARCH64_ADR_PREL_PG_HI21 stg_upd_frame_info }}} although there are plenty of others. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15861: Cannot import (*) type operator
by GHC 06 Nov '18

06 Nov '18

#15861: Cannot import (*) type operator -------------------------------------+------------------------------------- Reporter: pgujjula | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The (*) type operator cannot be imported from GHC.TypeLits. The following code compiles in GHC 8.4.4 but fails in GHC 8.6.1 with "error: parse error on input ‘*’" {{{#!hs {-# LANGUAGE TypeOperators #-} import GHC.TypeLits (type (*)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15861> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15559: fromJust has no HasCallStack
by GHC 06 Nov '18

06 Nov '18

#15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | 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: -------------------------------------+------------------------------------- The function `Data.Maybe.fromJust` does not have a `HasCallStack` constraint. I wonder why – is that intentional, or did just nobody bother yet? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15560: Full laziness destroys opportunities for join points
by GHC 05 Nov '18

05 Nov '18

#15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14287 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Even if we already know a binding is a join point we STILL float it to the top and turn it into a function. The simple example below results in a join point after the first simplifier run. Then we run the float out pass immediately undoing this by making it a top level binding. It then stays at the top till we are done resulting in the core I've put in the comments. {{{ #!haskell data T = A | B | C | D | E | F | G {-# NOINLINE n #-} n :: T -> T n A = B n B = C n _ = A f :: Int -> T -> T -> T f sel x y = -- function large enough to avoid being simply inlined let j z = n . n . n . n . n . n $ z in case sel of -- j is always tailcalled 0 -> j x _ -> j y -- j is floated to top level instead of ending up as joinpoint. -- T.f_j -- = \ (eta_B1 [OS=OneShot] :: T) -> n (n (n (n (n (n eta_B1))))) -- -- RHS size: {terms: 14, types: 6, coercions: 0, joins: 0/0} -- f :: Int -> T -> T -> T -- f = \ (sel_aYP :: Int) (x_aYQ :: T) (y_aYR :: T) -> -- case sel_aYP of { GHC.Types.I# ds_d2fL -> -- case ds_d2fL of { -- __DEFAULT -> T.f_j y_aYR; -- 0# -> T.f_j x_aYQ -- } -- } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #15009: Float equalities past local equalities
by GHC 05 Nov '18

05 Nov '18

#15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.3 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: -------------------------------------+------------------------------------- Consider the two datatypes {{{#!hs data T1 a where MkT1 :: a ~ b => b -> T1 a data T2 a where MkT2 :: a -> T2 a }}} To me, these look like two ways of writing the same thing. Yet they participate quite differently in type inference. If I say {{{#!hs f (MkT1 a) = not a g (MkT2 a) = not a }}} then `g` is accepted (with type `T2 Bool -> Bool`) while `f` is rejected as GHC mutters about untouchable type variables. Of course, GHC's notion of untouchable type variables is a Good Thing, with arguments I won't rehearse here. It all boils down to this rule: (*) Information that arises in the context of an equality constraint cannot force unification of a unification variable born outside that context. I think this rule is a bit too strict, though. I propose a new rule: (%) Information that arises in the context of a ''non-purely-local'' equality constraint cannot force unification of a unification variable born outside that context. where '''Definition:''' An equality constraint is ''purely local'' if every type variable free in the constraint has the same scope as the constraint itself. That is, if an equality constraint mentions only variables freshly brought into scope -- and no others -- then we can still unify outer unification variables. Happy consequences of this choice: * `f` above could be accepted, as the equality in `MkT1` is purely local. * Rule (%) allows users to effectively let-bind type variables, like this: {{{#!hs f :: forall a. (a ~ SOME REALLY LONG TYPE) => Maybe a -> Maybe a -> Either a a }}} Currently, this kind of definition (if it's, say, within a `where` clause) triggers rule (*) in the body of the function, and thus causes type inference to produce a different result than just inlining `SOME REALLY LONG TYPE`. * We could theoretically simplify our treatment of GADTs. Right now, if you say {{{#!hs data G a b c where MkG :: MkG d Int [e] }}} GHC has to cleverly figure out that `d` is a universal variable and that `e` is an existential, producing the following Core: {{{#!hs data G a b c where MkG :: forall d b c. forall e. (b ~ Int, c ~ [e]) => MkG d b c }}} If we use rule (%), then I believe the following Core would behave identically: {{{#!hs data G a b c where MkG :: forall a b c. forall d e. (a ~ d, b ~ Int, c ~ [e]). MkG a b c }}} This treatment is more uniform and easier to implement. (Note that the equality constraints themselves are unboxed, so there's no change in runtime performance.) What are the downsides of (%)? I don't think there are any, save an easy extra line or two in GHC to check for locality. Rule (*) exists because, without it, GHC can infer non-principal types. However, I conjecture that Rule (%) also serves to require inference of only principal types, while being more permissive than Rule (*). I'm curious for your thoughts on this proposal. (I am making it here, as this is really an implementation concern, with no discernible effect on, say, the user manual, although it would allow GHC to accept more programs.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13904: LLVM does not need to trash callee-saved registers.
by GHC 03 Nov '18

03 Nov '18

#13904: LLVM does not need to trash callee-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: llvm, codegen | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #4992 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **Summary**: This ticket is a simplification of the LLVM backend that I already plan to do in another branch, but I'd like to push the patch into `master`, and then merge from `master` into that branch. The LLVM backend attempts to trash the physical registers corresponding to Rx, Fx, and Dx registers that are caller-saved before an FFI call by emitting a sequence such as this: {{{#!llvm store i64 undef, i64* %R3_Var store i64 undef, i64* %R4_Var store i64 undef, i64* %R5_Var store i64 undef, i64* %R6_Var store float undef, float* %F1_Var store double undef, double* %D1_Var store float undef, float* %F2_Var store double undef, double* %D2_Var store float undef, float* %F3_Var store double undef, double* %D3_Var store float undef, float* %F4_Var store double undef, double* %D4_Var store float undef, float* %F5_Var store double undef, double* %D5_Var store float undef, float* %F6_Var store double undef, double* %D6_Var %ln7bu = call ccc double (double) @llvm.sin.f64( double %ln7bs ) nounwind }}} Where the Rx/Fx/Dx registers are chosen based on what physical register those global registers map to, and whether those physical registers are caller-saved according to the C ABI. I'm certain this is unnecessary, as there is no way to know the physical register corresponding to those vars within an LLVM IR function. The calling convention used for the FFI call will preserve caller-saved registers as needed, i.e., only if such a value is needed after the call. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13