- ghc-tickets - Haskell.org

[GHC] #16323: Cannot deduce X error with X provided
by GHC 15 Feb '19

15 Feb '19

#16323: Cannot deduce X error with X provided ----------------------------------------+--------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The following code {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} module TorXakis.Test ( -- * Referable Referable(..) ) where import Data.Hashable import qualified Data.HashMap as HashMap -- | A referable class class Referable a where type Ref a toRef :: a -> Ref a -- | Map of Referable objects. data (Referable a, Ord (Ref a), Hashable (Ref a)) => RefMap a = RefMap { -- | the HashMap toHashMap :: HashMap.Map (Ref a) a } deriving (Eq, Ord, Show, Read) }}} gives the following errors {{{ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:43: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Eq a, Referable a) bound by the deriving clause for `Eq (RefMap a)' at src\TorXakis\Test.hs:20:43-44 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Eq (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:47: error: * Could not deduce (Hashable (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Ord a, Referable a) bound by the deriving clause for `Ord (RefMap a)' at src\TorXakis\Test.hs:20:47-49 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Ord (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:52: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Show a, Referable a) bound by the deriving clause for `Show (RefMap a)' at src\TorXakis\Test.hs:20:52-55 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Show (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:58: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Read a, Referable a) bound by the deriving clause for `Read (RefMap a)' at src\TorXakis\Test.hs:20:58-61 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Read (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ -- While building package txs-basics-0.1.0.0 using: C:\sr\setup-exe-cache\x86_64-windows-integersimple\Cabal- simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.stack-w ork\dist\67675594 build lib:txs-basics --ghc-options " -ddump-hi -ddump- to-file" Process exited with code: ExitFailure 1 }}} yet the requirements such as {{{Ord (Ref a)}}} are clearly given to the data definition! possibly related to #16319 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations
by GHC 15 Feb '19

15 Feb '19

#16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | 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: -------------------------------------+------------------------------------- Phab:D5180 introduced a slight regression to the error messages. In this code {{{#!hs data T = forall a. MkT a }}} GHC used to complain {{{ rnfail053.hs:5:10: Not a data constructor: ‘forall’ Perhaps you intended to use ExistentialQuantification }}} but then the message has become {{{ rnfail053.hs:5:18: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16176: Let-insertion for template haskell
by GHC 15 Feb '19

15 Feb '19

#16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple TypedTemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using Template Haskell to generate programs it's very easy to end up with a lot of duplication as splices are naively spliced in place. For example {{{ foo x = [|| $$x + $$x ||] }}} Will generate a program which completely duplicates its argument. In this case I can manually remove the duplicate by inserting a let. {{{ foo x = [|| let x' = $$x in x' + x' ||] }}} Not too bad but a bit annoying to have to do manually. When constructing bigger programs however this process becomes tedious or impossible to do correctly by hand. {{{ foo :: (Q (TExp (Bool)) -> Q (TExp Int)) -> Q (TExp Int) foo xf = [|| (let x = True in $$(xf [|| x ||])) + (let x = False in $$(xf [|| x ||]) ||] }}} Now if I pass a constant function to `foo`, the resulting code won't mention `x` so it could be floated out. However, there's not way I can tell that without running `xf` so I can't perform the same transformation as I did for the earlier program and manually insert a let. In the case of splicing in fully static data you really want it to float to the top-level and turn into a CAF. The proposal of this ticket is to implement something like the mechanism for let-insertion in metaocaml. http://okmij.org/ftp/meta-programming/#let-insert We add two new primitives: {{{ genlet :: Q (TExp a) -> Q (TExp a) let_locus :: Q (TExp a) -> Q (TExp a) }}} `genlet` marks a code value that we want to float. `let_locus` marks places where we want to insert a let. When we evaluate the code fragment and encounter a `genlet` call, whatever the argument evaluates to is floated as far upwards as possible and inserted at the position of one of the loci. For example, {{{ sqr :: Code Int -> Code Int sqr c = [|| $$c + $$c ||] sqr_let :: Code Int -> Code Int sqr_let c = let_locus (sqr (genlet c)) }}} Splicing `sqr [|| 1 ||]` will result in `1 + 1` but `sqr_let [|| c ||]` will equal `let x = 1 in x + x ||]`. It's important to do this earlier rather than later as a lot of duplication can take place which the simplifier does not like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16324: ghc-pkg: Batched package unregister takes time linear to the batch size
by GHC 15 Feb '19

15 Feb '19

#16324: ghc-pkg: Batched package unregister takes time linear to the batch size -------------------------------------+------------------------------------- Reporter: qrilka | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- When started using batched `ghc-pkg unregister` (implemented in #12637) we have noticed that it did not give much time speed improvements. I've created a simple reproduction of that behavior in https://github.com/qrilka/pkg-db-problems (which is a bit of package db abuse of cause as the same package gets registered multiple times with different ids). The last run of that script gave me: {{{ qrilka@qdesktop ~/ws/h/pkg-db-problems $ ./test.sh Up to date Reading package info from "dist- newstyle/packagedb/ghc-8.6.3/sample-1.0.0-inplace.conf" ... done. sample-1.0.0: Warning: haddock-interfaces: /home/qrilka/ws/h/pkg-db- problems/dist- newstyle/build/x86_64-linux/ghc-8.6.3/sample-1.0.0/doc/html/sample/sample.haddock doesn't exist or isn't a file sample-1.0.0: Warning: haddock-html: /home/qrilka/ws/h/pkg-db-problems /dist-newstyle/build/x86_64-linux/ghc-8.6.3/sample-1.0.0/doc/html/sample doesn't exist or isn't a directory Unregistering single package: real 0m0,196s user 0m0,175s sys 0m0,020s Unregistering 15 packages: real 0m2,471s user 0m2,340s sys 0m0,130s }}} Which clearly shows speed problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16321: Suggest -XScopedTypeVariables instead of -XRankNTypes
by GHC 14 Feb '19

14 Feb '19

#16321: Suggest -XScopedTypeVariables instead of -XRankNTypes -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | 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: -------------------------------------+------------------------------------- When the parser encounters an explicit `forall` when `-XExplicitForAll` is disabled, it tries to guess what the user meant and suggests to enable `-XRankNTypes`: {{{ Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> }}} Richard argues we are better off suggesting `-XScopedTypeVariables` by default: > Consider these workflows: > > 1a. User is writing a higher-rank type without extensions. GHC suggests to enable RankNTypes. Program is accepted. > > 1b. User is writing a higher-rank type without extensions. GHC suggests to enable ScopedTypeVariables. User compiles again, and GHC suggests to enable RankNTypes. Program is accepted. > > 2a. User is writing a program that requires scoped type variables. GHC suggests to enable RankNTypes. Program is rejected with inscrutable type errors claiming that `a` is not `a0`. > > 2b. User is writing a program that requires scoped type variables. GHC suggests to enable ScopedTypeVariables. Program is accepted. > > The question is: what's worse: 1b, or 2a? I claim that 2a is worse, and so I favor making the change so that we avoid 2a in favor of sometimes incurring 1b. The problem here is that in the grand scheme of things, we want neither 1b nor 2a to happen. What would it take to implement a proper diagnostic and always suggest the appropriate extension? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15579: topNormaliseType is wrong
by GHC 14 Feb '19

14 Feb '19

#15579: topNormaliseType is wrong -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- I’m very puzzled about topNormaliseTYpe_maybe. Here it is: {{{ topNormaliseType_maybe env ty = topNormaliseTypeX stepper mkTransCo ty where stepper = unwrapNewTypeStepper `composeSteppers` tyFamStepper tyFamStepper rec_nts tc tys -- Try to step a type/data family = let (args_co, ntys) = normaliseTcArgs env Representational tc tys in -- NB: It's OK to use normaliseTcArgs here instead of -- normalise_tc_args (which takes the LiftingContext described -- in Note [Normalising types]) because the reduceTyFamApp below -- works only at top level. We'll never recur in this function -- after reducing the kind of a bound tyvar. case reduceTyFamApp_maybe env Representational tc ntys of Just (co, rhs) -> NS_Step rec_nts rhs (args_co `mkTransCo` co) _ -> NS_Done }}} I have two puzzlements 1. First, it seems utterly wrong to normalise the arguments using Representational. Consider {{{ F (N Int) where newtype N x = [x] }}} We don’t want to reduce `(N Int)` to `[Int]`, and then try reducing `(F [Int])`!! That is totally bogus. Surely we should use (the role-aware) `normalise_tc_args` here? 2. I have literally no clue what `Note [Normalising types]` is all about. Moreover there is no Lifting Context passed to `normalise_tc_args`, so I don’t know what this stuff about `LiftingContext` is about. Is this historical baggage? Richard and I discussed this. (1) is a bug; for (2) the comment is misleading and should be deleted. Richard will do these things -- and will add examples to the mysterious `Note [Normalising types]` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks
by GHC 14 Feb '19

14 Feb '19

#11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- After #11549, we are suppose not to show `RuntimeRep` to users, when `-fno-print-explicit-runtime-reps` is on. But we do: {{{ :info ($) Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ }}} This happens because the runtime-rep-suppression happens on `Type`, but for `:info` we use `pprInfo` which uses `tyThingToIfaceDecl` and then prints it. And `tyThingToIfaceDecl` doesn't know about the `-fprint- explicit-runtime-reps` flag; and I'd like to keep it that way. We want to change `pprType` to convert to `IfaceType` and then print anyway. I suppose that this means that the pretty-printer for `IfaceType` needs to know about this runtime-rep suppression. That's a bit tiresome, but not impossible, especially since there is no shadowing to worry about. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #16228: ghc-pkg and ghc do not agree about package with internal libraries
by GHC 14 Feb '19

14 Feb '19

#16228: ghc-pkg and ghc do not agree about package with internal libraries --------------------------------------+--------------------------------- Reporter: michaelpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Initially I reported this to Cabal (https://github.com/haskell/cabal/issues/5857) but I think this is actually a GHC bug. Repro here: https://github.com/michaelpj/cabal-bug-package-db In particular, you can run the following. {{{ $ cabal build $ ghc-pkg field test exposed -f dist/package.conf.inplace exposed: True $ ghc-pkg find-module Test -f dist/package.conf.inplace dist/package.conf.inplace test-0.1.0.0 $ ghc -package-db dist/package.conf.inplace Use.hs [1 of 1] Compiling Use ( Use.hs, Use.o ) Use.hs:3:1: error: Could not load module ‘Test’ It is a member of the hidden package ‘test-0.1.0.0’. You can run ‘:set -package test’ to expose it. (Note: this unloads all the modules in the current scope.) Use -v to see a list of the files searched for. | 3 | import Test | ^^^^^^^^^^^ $ ghc -package-db dist/package.conf.inplace -package test Use.hs [1 of 1] Compiling Use ( Use.hs, Use.o ) }}} That is: * `ghc-pkg` thinks the package is present, exposed, and contains the module in question. * `ghc` thinks the package is hidden, and will accept it when specified with `-package`. If you comment out the internal library this does not happen, but regardless it seems bad that there's a disagreement between `ghc-pkg` and `ghc`. I've also observed (although I don't have a small reproduction for this) a similar case where `ghc` does not even think the module is hidden, but again will accept it with `-package`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10187: Panic: RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order; bad blockId c8xHd
by GHC 14 Feb '19

14 Feb '19

#10187: Panic: RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order; bad blockId c8xHd -----------------------------------+--------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: #9541, #9031 Differential Revisions: | -----------------------------------+--------------------------------------- I’ve found another instance of the elusive `RegAlloc.Liveness.computeLivenss` bug, by attempting to bootstrap ''cabal-install'' 1.20.0.6 with GHC 7.8.4 on 32-bit CentOS 6, released on 27/05/2013 (available on [https://aws.amazon.com/marketplace/pp/B00A6KZBC6/ Amazon EC2]). Unfortunately, I’m unable to reproduce the bug on a subsequent attempt. Cosmic rays? {{{ Configuring text-1.1.0.1... Building text-1.1.0.1... Preprocessing library text-1.1.0.1... [ 1 of 43] Compiling Data.Text.Internal.Read ( Data/Text/Internal/Read.hs, dist/build/Data/Text/Internal/Read.o ) [ 2 of 43] Compiling Data.Text.Internal.Encoding.Utf32 ( Data/Text/Internal/Encoding/Utf32.hs, dist/build/Data/Text/Internal/Encoding/Utf32.o ) [ 3 of 43] Compiling Data.Text.Internal.Fusion.Size ( Data/Text/Internal/Fusion/Size.hs, dist/build/Data/Text/Internal/Fusion/Size.o ) [ 4 of 43] Compiling Data.Text.Internal.Builder.RealFloat.Functions ( Data/Text/Internal/Builder/RealFloat/Functions.hs, dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o ) [ 5 of 43] Compiling Data.Text.Internal.Builder.Int.Digits ( Data/Text/Internal/Builder/Int/Digits.hs, dist/build/Data/Text/Internal/Builder/Int/Digits.o ) [ 6 of 43] Compiling Data.Text.Internal.Fusion.Types ( Data/Text/Internal/Fusion/Types.hs, dist/build/Data/Text/Internal/Fusion/Types.o ) [ 7 of 43] Compiling Data.Text.Internal.Fusion.CaseMapping ( Data/Text/Internal/Fusion/CaseMapping.hs, dist/build/Data/Text/Internal/Fusion/CaseMapping.o ) [ 8 of 43] Compiling Data.Text.Encoding.Error ( Data/Text/Encoding/Error.hs, dist/build/Data/Text/Encoding/Error.o ) [ 9 of 43] Compiling Data.Text.Internal.Unsafe.Shift ( Data/Text/Internal/Unsafe/Shift.hs, dist/build/Data/Text/Internal/Unsafe/Shift.o ) [10 of 43] Compiling Data.Text.Internal.Encoding.Utf16 ( Data/Text/Internal/Encoding/Utf16.hs, dist/build/Data/Text/Internal/Encoding/Utf16.o ) [11 of 43] Compiling Data.Text.Internal.Functions ( Data/Text/Internal/Functions.hs, dist/build/Data/Text/Internal/Functions.o ) [12 of 43] Compiling Data.Text.Internal.Unsafe ( Data/Text/Internal/Unsafe.hs, dist/build/Data/Text/Internal/Unsafe.o ) [13 of 43] Compiling Data.Text.Internal.Fusion.Common ( Data/Text/Internal/Fusion/Common.hs, dist/build/Data/Text/Internal/Fusion/Common.o ) [14 of 43] Compiling Data.Text.Array ( Data/Text/Array.hs, dist/build/Data/Text/Array.o ) [15 of 43] Compiling Data.Text.Internal.Unsafe.Char ( Data/Text/Internal/Unsafe/Char.hs, dist/build/Data/Text/Internal/Unsafe/Char.o ) [16 of 43] Compiling Data.Text.Internal ( Data/Text/Internal.hs, dist/build/Data/Text/Internal.o ) [17 of 43] Compiling Data.Text.Unsafe ( Data/Text/Unsafe.hs, dist/build/Data/Text/Unsafe.o ) [18 of 43] Compiling Data.Text.Internal.Private ( Data/Text/Internal/Private.hs, dist/build/Data/Text/Internal/Private.o ) [19 of 43] Compiling Data.Text.Internal.Fusion ( Data/Text/Internal/Fusion.hs, dist/build/Data/Text/Internal/Fusion.o ) [20 of 43] Compiling Data.Text.Internal.Encoding.Fusion.Common ( Data/Text/Internal/Encoding/Fusion/Common.hs, dist/build/Data/Text/Internal/Encoding/Fusion/Common.o ) [21 of 43] Compiling Data.Text.Internal.Encoding.Utf8 ( Data/Text/Internal/Encoding/Utf8.hs, dist/build/Data/Text/Internal/Encoding/Utf8.o ) [22 of 43] Compiling Data.Text.Internal.Encoding.Fusion ( Data/Text/Internal/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Encoding/Fusion.o ) [23 of 43] Compiling Data.Text.Internal.Lazy.Encoding.Fusion ( Data/Text/Internal/Lazy/Encoding/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o ) [24 of 43] Compiling Data.Text.Internal.Search ( Data/Text/Internal/Search.hs, dist/build/Data/Text/Internal/Search.o ) [25 of 43] Compiling Data.Text ( Data/Text.hs, dist/build/Data/Text.o ) [26 of 43] Compiling Data.Text.Encoding ( Data/Text/Encoding.hs, dist/build/Data/Text/Encoding.o ) [27 of 43] Compiling Data.Text.Foreign ( Data/Text/Foreign.hs, dist/build/Data/Text/Foreign.o ) [28 of 43] Compiling Data.Text.Internal.IO ( Data/Text/Internal/IO.hs, dist/build/Data/Text/Internal/IO.o ) [29 of 43] Compiling Data.Text.IO ( Data/Text/IO.hs, dist/build/Data/Text/IO.o ) [30 of 43] Compiling Data.Text.Internal.Lazy ( Data/Text/Internal/Lazy.hs, dist/build/Data/Text/Internal/Lazy.o ) [31 of 43] Compiling Data.Text.Internal.Lazy.Fusion ( Data/Text/Internal/Lazy/Fusion.hs, dist/build/Data/Text/Internal/Lazy/Fusion.o ) [32 of 43] Compiling Data.Text.Internal.Lazy.Search ( Data/Text/Internal/Lazy/Search.hs, dist/build/Data/Text/Internal/Lazy/Search.o ) [33 of 43] Compiling Data.Text.Lazy.Internal ( Data/Text/Lazy/Internal.hs, dist/build/Data/Text/Lazy/Internal.o ) [34 of 43] Compiling Data.Text.Lazy ( Data/Text/Lazy.hs, dist/build/Data/Text/Lazy.o ) [35 of 43] Compiling Data.Text.Internal.Builder ( Data/Text/Internal/Builder.hs, dist/build/Data/Text/Internal/Builder.o ) [36 of 43] Compiling Data.Text.Lazy.Builder ( Data/Text/Lazy/Builder.hs, dist/build/Data/Text/Lazy/Builder.o ) [37 of 43] Compiling Data.Text.Internal.Builder.Functions ( Data/Text/Internal/Builder/Functions.hs, dist/build/Data/Text/Internal/Builder/Functions.o ) [38 of 43] Compiling Data.Text.Lazy.Builder.Int ( Data/Text/Lazy/Builder/Int.hs, dist/build/Data/Text/Lazy/Builder/Int.o ) [39 of 43] Compiling Data.Text.Lazy.IO ( Data/Text/Lazy/IO.hs, dist/build/Data/Text/Lazy/IO.o ) [40 of 43] Compiling Data.Text.Lazy.Read ( Data/Text/Lazy/Read.hs, dist/build/Data/Text/Lazy/Read.o ) [41 of 43] Compiling Data.Text.Lazy.Builder.RealFloat ( Data/Text/Lazy/Builder/RealFloat.hs, dist/build/Data/Text/Lazy/Builder/RealFloat.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for i386-unknown-linux): RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c8xHd [NONREC c8xHG: jmp *-4(%ebx), NONREC c8xHF: movl $12,828(%ebx) jmp *stg_gc_unpt_r1@got(%vI_n8Wmo), NONREC c8xHE: movl %vI_n8Wmo,%vI_n8WmH addl $sat_s8qTs{v}_info@gotoff,%vI_n8WmH movl %vI_n8WmH,-8(%edi) movl 4(%ebp),%vI_n8WmI movl %vI_n8WmI,-4(%edi) movl 16(%ebp),%vI_n8WmJ movl %vI_n8WmJ,(%edi) leal -7(%edi),%esi addl $20,%ebp jmp *(%ebp), NONREC c8xHz: movl $48,828(%ebx) movl %vI_n8Wmo,%vI_n8WmF addl $block{v c8xEh}_info@gotoff,%vI_n8WmF movl %vI_n8WmF,(%ebp) movl %vI_s8qTz,%esi movl %vI_s8qTx,4(%ebp) jmp *stg_gc_unbx_r1@got(%vI_n8Wmo), NONREC c8xHq: movl %vI_c8xEw,%esi incl 8(%ebp) addl $8,%ebp jmp *stg_ap_n_fast@got(%vI_n8Wmo), NONREC c8xHp: movl %vI_c8xEw,%esi addl $8,%ebp jmp *stg_ap_n_fast@got(%vI_n8Wmo), NONREC c8xHi: jmp *(%esi), NONREC c8xGZ: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl 4(%ebp),%vI_c8xEw movl %esi,%vI_n8Wmw andl $3,%vI_n8Wmw cmpl $2,%vI_n8Wmw jae _c8xHp jmp _c8xHq, NONREC c8xHy: movl %vI_n8Wmo,%vI_n8Wmy addl $lvl65{v s8qTB}_info@gotoff,%vI_n8Wmy movl %vI_n8Wmy,-44(%edi) movl %vI_s8qTz,-36(%edi) movl %vI_n8Wmo,%vI_n8WmA addl $a28{v s8qTD}_info@gotoff,%vI_n8WmA movl %vI_n8WmA,-32(%edi) movl %vI_s8qTd,-28(%edi) movl %vI_s8qTh,-24(%edi) movl %vI_s8qTk,-20(%edi) movl %vI_s8qTx,-16(%edi) leal -44(%edi),%vI_c8xEn movl %vI_c8xEn,-12(%edi) movl %vI_s8qRK,-8(%edi) movl %vI_s8qTj,-4(%edi) movl %vI_s8qTz,(%edi) movl %vI_n8Wmo,%vI_n8WmC addl $block{v c8xGZ}_info@gotoff,%vI_n8WmC movl %vI_n8WmC,16(%ebp) movl %vI_c8xEn,%esi leal -30(%edi),%vI_n8WmD movl %vI_n8WmD,20(%ebp) addl $16,%ebp testl $3,%esi jne _c8xGZ jmp _c8xHi, NONREC c8xGX: addl $12,%edi cmpl 804(%ebx),%edi ja _c8xHF jmp _c8xHE, NONREC c8xEi: addl $48,%edi cmpl 804(%ebx),%edi ja _c8xHz jmp _c8xHy, NONREC c8xHe: movl %esi,%vI_s8qTx movl $65533,%vI_s8qTz jmp _c8xEi, NONREC c8xEh: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl 20(%ebp),%vI_s8qRK movl 12(%ebp),%vI_s8qTd movl 16(%ebp),%vI_s8qTh movl 24(%ebp),%vI_s8qTj movl 8(%ebp),%vI_s8qTk movl 4(%ebp),%vI_s8qTx movl %esi,%vI_s8qTz jmp _c8xEi, NONREC c8xEb: jmp *(%esi), NONREC c8xEa: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl 20(%ebp),%vI_s8qRK movl 12(%ebp),%vI_s8qTd movl 16(%ebp),%vI_s8qTh movl 24(%ebp),%vI_s8qTj movl 8(%ebp),%vI_s8qTk movl 4(%ebp),%vI_s8qTw movl %vI_s8qTw,%vI_n8Wms andl $2095104,%vI_n8Wms cmpl $55296,%vI_n8Wms jne _c8xHd jmp _c8xHe, NONREC c8xE6: jmp *(%esi), NONREC c8xE5: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl %vI_n8Wmo,%vI_n8Wmq addl $block{v c8xEa}_info@gotoff,%vI_n8Wmq movl %vI_n8Wmq,(%ebp) movl 3(%esi),%vI_s8qTw movl 4(%ebp),%esi movl %vI_s8qTw,4(%ebp) testl $3,%esi jne _c8xEa jmp _c8xEb, NONREC c8xGW: movl %vI_n8Wmo,%vI_n8Wmu addl $block{v c8xE5}_info@gotoff,%vI_n8Wmu movl %vI_n8Wmu,-8(%ebp) movl %esi,%vI_s8qTk movl 6(%esi),%vI_s8qTu movl 2(%esi),%esi movl %vI_s8qTu,-4(%ebp) movl %vI_s8qTk,(%ebp) addl $-8,%ebp testl $3,%esi jne _c8xE5 jmp _c8xE6, NONREC c8xDC: jmp *(%esi), NONREC c8xDB: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo movl %esi,%vI_n8Wmn andl $3,%vI_n8Wmn cmpl $2,%vI_n8Wmn jae _c8xGW jmp _c8xGX, NONREC c8xHH: movl %vI_n8Wmo,%vI_n8WmL addl $block{v c8xDB}_info@gotoff,%vI_n8WmL movl %vI_n8WmL,-12(%ebp) movl %esi,%vI_s8qTh movl 2(%esi),%vI_s8qTd movl 6(%esi),%vI_s8qRK movl (%ebp),%esi movl %vI_s8qTd,-8(%ebp) movl %vI_s8qTh,-4(%ebp) movl %vI_s8qRK,(%ebp) addl $-12,%ebp testl $3,%esi jne _c8xDB jmp _c8xDC, NONREC c8xGY: call 1f 1: popl %vI_n8Wmo addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %vI_n8Wmo leal -20(%ebp),%vI_n8Wml cmpl 796(%ebx),%vI_n8Wml jb _c8xHG jmp _c8xHH] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just
by GHC 14 Feb '19

14 Feb '19

#10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just -----------------------------------+--------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- On 32-bit Red Hat Enterprise Linux 6.5, released on 11/11/2014 (available on [https://aws.amazon.com/marketplace/pp/B007NMF9O0/ Amazon EC2]), building `attoparsec-0.12.1.2` with GHC 7.8.4 causes a panic: {{{ Configuring attoparsec-0.12.1.2... Building attoparsec-0.12.1.2... Preprocessing library attoparsec-0.12.1.2... [ 1 of 21] Compiling Data.Attoparsec.Text.FastSet ( Data/Attoparsec/Text/FastSet.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/FastSet.o ) [ 2 of 21] Compiling Data.Attoparsec.Text.Buffer ( Data/Attoparsec/Text/Buffer.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/Buffer.o ) [ 3 of 21] Compiling Data.Attoparsec.Internal.Fhthagn ( Data/Attoparsec/Internal/Fhthagn.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal/Fhthagn.o ) [ 4 of 21] Compiling Data.Attoparsec.ByteString.Buffer ( Data/Attoparsec/ByteString/Buffer.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/Buffer.o ) [ 5 of 21] Compiling Data.Attoparsec.Zepto ( Data/Attoparsec/Zepto.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Zepto.o ) [ 6 of 21] Compiling Data.Attoparsec.Number ( Data/Attoparsec/Number.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Number.o ) [ 7 of 21] Compiling Data.Attoparsec.ByteString.FastSet ( Data/Attoparsec/ByteString/FastSet.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/FastSet.o ) [ 8 of 21] Compiling Data.Attoparsec.Internal.Types ( Data/Attoparsec/Internal/Types.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal/Types.o ) [ 9 of 21] Compiling Data.Attoparsec.Types ( Data/Attoparsec/Types.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Types.o ) [10 of 21] Compiling Data.Attoparsec.Internal ( Data/Attoparsec/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal.o ) [11 of 21] Compiling Data.Attoparsec.Combinator ( Data/Attoparsec/Combinator.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Combinator.o ) [12 of 21] Compiling Data.Attoparsec.ByteString.Internal ( Data/Attoparsec/ByteString/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/Internal.o ) [13 of 21] Compiling Data.Attoparsec.Text.Internal ( Data/Attoparsec/Text/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/Internal.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for i386-unknown-linux): compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs:84:13-59: Irrefutable pattern failed for pattern Data.Maybe.Just live_set }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3