- ghc-tickets - Haskell.org

[GHC] #10760: Conflicting typefamily instances not reported with polykinds
by GHC 11 Aug '15

11 Aug '15

#10760: Conflicting typefamily instances not reported with polykinds -------------------------------------+------------------------------------- Reporter: steely | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC fails to report conflicting instances for a open polykinded type family when the two resulting types have different kinds. I would expect conflicts to be detected regardless of the concrete kind of the result. Minimal Example: {{{#!hs type family Bar a :: k type instance Bar Int = Int --type instance Bar Int = Bool -- Conflict detected type instance Bar Int = [] -- Conflict NOT detected }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10742: GHC cannot deduce (irrelevant) reflexive type equality.
by GHC 11 Aug '15

11 Aug '15

#10742: GHC cannot deduce (irrelevant) reflexive type equality. -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: TypeLits | Operating System: Linux GADTs | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC is creating an irrelevant reflexive type equality and then failing to deduce it. The problem seems to be related to transitivity for `GHC.TypeLits.Nat`, as the example will make clear. Example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} module TypeLitsBug where import GHC.TypeLits data T a where MkT :: T Int test :: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) => proxy x y z -> () test _ = case MkT of MkT -> () }}} Error message: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ ghc -c TypeLitsBug.hs TypeLitsBug.hs:11:9: Could not deduce ((x <=? z) ~ (x <=? z)) from the context ((x <=? y) ~ 'True, (y <=? z) ~ 'True) bound by the type signature for test :: ((x <=? y) ~ 'True, (y <=? z) ~ 'True) => proxy x y z -> () at TypeLitsBug.hs:(11,9)-(12,25) NB: ‘<=?’ is a type function, and may not be injective }}} Notice the `x <=? z` relating `x` to `z`. I only mention `x <=? y` and `y <=? z` in the program, so it seems transitivity of `<=` is implicitly involved. Also, the problem goes away if I remove the GADT pattern match. I asked Iavor about this and he suspected the ambiguity check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10763: Failure to build GHC HEAD with 7.8 due to lint error
by GHC 11 Aug '15

11 Aug '15

#10763: Failure to build GHC HEAD with 7.8 due to lint error -------------------------------------+------------------------------------- Reporter: nomeata | 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 Revisions: | -------------------------------------+------------------------------------- I’m trying to build GHC HEAD, but it fails for me: {{{ ~/build/haskell/ghc $ make -j4 ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds HC [stage 0] compiler/stage1/build/Coercion.o ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Iface Lint failure In interface for ghc-7.11:CoAxiom Unfolding of ghc-7.11:CoAxiom.$fTypeableCoAxiom{v ryD} <no location info>: Warning: [in an imported unfolding] Ill-kinded result in type or kind ‘ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}’ type or kind ‘ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}’ kind: ghc- prim:GHC.Prim.BOX{(w) tc 347} <no location info>: Warning: [in an imported unfolding] Bad axiom application (check_ki2 <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}>_N ghc-prim:GHC.Prim.*{(w) tc 34d} k{tv a8xP} [tv] ghc-prim:GHC.Prim.BOX{(w) tc 347}) base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}>_N <ghc-7.11:CoAxiom.CoAxiom{tc r6O}>_N ghc-7.11:CoAxiom.$fTypeableCoAxiom{v ryD} = ghc-7.11:CoAxiom.$fTypeableCoAxiom_$ctypeRep#{v rzw} [gid] `cast` (Sym (base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc- prim:GHC.Prim.*{(w) tc 34d}>_N <ghc-7.11:CoAxiom.CoAxiom{tc r6O}>_N) :: (ghc- prim:GHC.Prim.Proxy#{(w) tc 38w} ghc-7.11:CoAxiom.CoAxiom{tc r6O} -> base:Data.Typeable.Internal.TypeRep{tc r9z}) ~# base:Data.Typeable.Internal.Typeable{tc 2k} ghc-7.11:CoAxiom.CoAxiom{tc r6O}) Iface expr = ghc-7.11:CoAxiom.$fTypeableCoAxiom_$ctypeRep#{v rzw} `cast` (Sym (base:Data.Typeable.Internal.NTCo:Typeable{tc r9X}[0] <ghc-7.11:CoAxiom.BranchFlag{tc rgu} -> ghc-prim:GHC.Prim.*{(w) tc 34d}>_N <ghc-7.11:CoAxiom.CoAxiom{tc r6O}>_N)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug compiler/ghc.mk:654: recipe for target 'compiler/stage1/build/Coercion.o' failed make[1]: *** [compiler/stage1/build/Coercion.o] Error 1 Makefile:103: recipe for target 'all' failed make: *** [all] Error 2 }}} Even if it turns out that this is a bug in 7.8 it would be nice to build HEAD out of the box with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10750: silly assembly for comparing Doubles
by GHC 10 Aug '15

10 Aug '15

#10750: silly assembly for comparing Doubles -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #10137, #10677 Differential Revisions: | -------------------------------------+------------------------------------- A function like `f x = if x > 0.0 then ... else ...` compiles to the assembly {{{ movsd 7(%rbx),%xmm0 xorpd %xmm1,%xmm1 ucomisd %xmm1,%xmm0 seta %al movzbl %al,%eax cmpq $1,%rax jb _c1tb }}} This `seta/movzbl/cmpq/jb` is bad, we can just generate `ja` (and 7.10 did). The cause is that the code generator produces Cmm like {{{ switch [0 .. 1] %MO_F_Gt_W64(_s1sv::F64, 0.0 :: W64)::I64 { case 0 : goto c1tb; case 1 : goto c1tc; } }}} which turns into {{{ if (%MO_F_Gt_W64(_s1sv::F64, 0.0 :: W64) < 1) goto c1tb; else goto c1tc; }}} and then GHC is stuck. It knows how to turn `condition >= 1` into `condition`, and it knows how to turn `condition < 1` into a negated version of `condition` when possible, but there is no negated version of `MO_F_Gt_W64` (it's not `MO_F_Le_W64` because of NaNs and signed zeros). It doesn't know how to turn a negated conditional into a conditional with the branches swapped because it doesn't look at that much at once. Presumably more fallout from #10137, and maybe can be fixed simultaneously with #10677. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10339: PatternSynonyms confuse exhaustiveness check
by GHC 10 Aug '15

10 Aug '15

#10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I just noticed some odd behaviour when (ab)using pattern synonyms in the following code (whose style I don't really endorse): {{{#!hs {-# LANGUAGE PatternSynonyms, LambdaCase #-} module PatSyn1 where import System.Directory (doesFileExist) pattern Found = True pattern NotFound = False readConfigFile :: FilePath -> IO () readConfigFile filePath = doesFileExist filePath >>= \case Found -> putStrLn =<< readFile filePath NotFound -> putStrLn "File does not exist." pattern Void = () foo :: () -> () foo Void = () }}} Results in {{{ /home/hvr/Haskell/PatSyn1.hs:(11,54)-(13,47): Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ /home/hvr/Haskell/PatSyn1.hs:19:1-13: Warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC
by GHC 10 Aug '15

10 Aug '15

#1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: I'm slowly reverting this work. There's no point in pretending GHC can still be compiled by other compilers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1405#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10758: the 'impossible' happened
by GHC 09 Aug '15

09 Aug '15

#10758: the 'impossible' happened -------------------------------------------+------------------------------- Reporter: martinmr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- I was working on solving problems 64 and 65 of the Euler project. When I was working on problem 64 I was able to load the file into ghci. I finished the problem and moved on to problem 65. When I tried to load 65.hs in ghci I got ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<6>() Same thing happened when I tried to load 64.hs (which used to work fine) and a number of other files from problems I had previously solved. Not all files trigger this issue and I have not changed ghc or cabal at all apart from installing the arithmoi and parallel packages. I am attaching my code for problems 64 and 65 in case my code is somehow triggering the bug (you can look at the problem statement at https://projecteuler.net/problem=64 and https://projecteuler.net/problem=65) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances
by GHC 08 Aug '15

08 Aug '15

#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nicolas Trangez points out that we don't have a `TypeRep` for types involving literal strings or numerics. E.g. what is `(typeRep (undefined :: Proxy "foo"))`? Here is Nicolas's example: {{{ {-# LANGUAGE DataKinds, KindSignatures, DeriveFunctor, DeriveDataTypeable #-} module Main where import Data.Typeable import GHC.TypeLits data NoSymbol n a b = NoSymbol a b deriving (Typeable) data WithSymbol (n :: Symbol) a b = WithSymbol a b deriving (Typeable) data Sym deriving (Typeable) main :: IO () main = do print $ typeOf (undefined :: NoSymbol Sym Int Int) let d = undefined :: WithSymbol "sym" Int Int {- print $ typeOf d No instance for (Typeable Symbol "sym") arising from a use of ‛typeOf’ -} return () }}} Just as types contain literal strings and natural numbers, so too must `TypeRep`, in some way. Once we have a suitable `TypeRep` we can make built-in instance for `Typeable` that return the appropriate representation. At the moment we have (in `Data.Typeable.Internals`): {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} with instances for Eq and Ord. Perhaps we need {{{ data TypeRep = TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep] | TcSym String | TcNat Integer }}} or something like that? I'm not certain. I think Iavor is going to think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 08 Aug '15

08 Aug '15

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: Incorrect result at runtime => Runtime performance bug Comment: Since RULES are usually (always?) defined for performance reasons, I'm grouping this with all other [https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Runtime+perfo… runtime performance bugs]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7374: rule not firing
by GHC 08 Aug '15

08 Aug '15

#7374: rule not firing -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7374#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0