- ghc-tickets - Haskell.org

[GHC] #13854: the 'impossible' happened initTc: unsolved constraints
by GHC 21 Jun '17

21 Jun '17

#13854: the 'impossible' happened initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [7 of 7] Compiling Texas.Api.OrderItems ( src/Texas/Api/OrderItems.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] OrderItemModified_a1mbC :: t_a1mbB[tau:1] (CHoleCan: OrderItemModified) [W] val_a1mbH :: t_a1mbG[tau:1] (CHoleCan: val) [W] runAccountDB_a1md0 :: t_a1mcZ[tau:1] (CHoleCan: runAccountDB) [W] getOrderItemsByOrderId_a1mdb :: t_a1mda[tau:1] (CHoleCan: getOrderItemsByOrderId)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have what I believe is a repro of this error, albeit slightly different, located here: https://github.com/bitemyapp/panic-repro-initTc-unsolved- constraints {{{ [3 of 3] Compiling Lib ( src/Lib.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Lib.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] over_amEW :: t_amEV[tau:1] (CHoleCan: over) [W] ix_amF5 :: t_amF4[tau:1] (CHoleCan: ix)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is the error I get there. If I learn more in the process of fixing the original code, I'll report it here. This panic occurs w/ GHC and GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7198: New codegen more than doubles compile time of T3294
by GHC 21 Jun '17

21 Jun '17

#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: michalt Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: simonmar => michalt Comment: Yes let's close it! I'll let you do the honours. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13849: Remove Binutils<2.17 hack in X86 codegen
by GHC 21 Jun '17

21 Jun '17

#13849: Remove Binutils<2.17 hack in X86 codegen -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The purpose of this ticket is to keep track of an hack that the X86 code generator uses to support binutils<2.17: nativeGen/X86/CodeGen.hs: > HACK: On x86_64 binutils<2.17 is only able to generate > PC32 relocations, hence we only get 32-bit offsets in > the jump table. As these offsets are always negative > we need to properly sign extend them to 64-bit. This > hack should be removed in conjunction with the hack in > PprMach.hs/pprDataItem once binutils 2.17 is standard. nativeGen/X86/Ppr.hs: > x86_64: binutils can't handle the R_X86_64_PC64 > relocation type, which means we can't do > pc-relative 64-bit addresses. Fortunately we're > assuming the small memory model, in which all such > offsets will fit into 32 bits, so we have to stick > to 32-bit offset fields and modify the RTS > appropriately > See Note [x86-64-relative] in includes/rts/storage/InfoTables.h includes/rts/storage/InfoTables.h > Note [x86-64-relative] > There is a complication on the x86_64 platform, where pointeres are > 64 bits, but the tools don't support 64-bit relative relocations. > However, the default memory model (small) ensures that all symbols > have values in the lower 2Gb of the address space, so offsets all > fit in 32 bits. Hence we can use 32-bit offset fields. > Somewhere between binutils-2.16.1 and binutils-2.16.91.0.6, > support for 64-bit PC-relative relocations was added, so maybe this > hackery can go away sometime. As binutils 2.17 is out since 2011, maybe we could remove this hack now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11758: Drop x86_64 binutils <2.17 hack
by GHC 21 Jun '17

21 Jun '17

#11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc2 (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: -------------------------------------+------------------------------------- `X86.CodeGen.genSwitch` contains this comment, {{{ else -- HACK: On x86_64 binutils<2.17 is only able to generate -- PC32 relocations, hence we only get 32-bit offsets in -- the jump table. As these offsets are always negative -- we need to properly sign extend them to 64-bit. This -- hack should be removed in conjunction with the hack in -- PprMach.hs/pprDataItem once binutils 2.17 is standard. }}} binutils 2.17 is now quite standard; even CentOS 5 shipped with 2.17. I think it is likely safe to remove this hack at this point. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13850: Incorrect function signature causes the impossible to happen
by GHC 21 Jun '17

21 Jun '17

#13850: Incorrect function signature causes the impossible to happen -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I made a mistake in my function signature: {{{ > cat wibble.hs ecase :: Either a b -> (a -> c) (b -> c) -> c ecase (Left a) f _ = f a ecase (Right b) _ g = g b > ghci wibble.hs GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/erikd/.ghci [1 of 1] Compiling Main ( wibble.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-linux): repSplitAppTys a_a1pA[sk:1] c_a1pC[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type }}} GHC 8.02 correctly reports an error: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/erikd/.ghci [1 of 1] Compiling Main ( wibble.hs, interpreted ) wibble.hs:1:24: error: • Expecting one fewer argument to ‘a -> c’ Expected kind ‘* -> *’, but ‘a -> c’ has kind ‘*’ • In the type signature: ecase :: Either a b -> (a -> c) (b -> c) -> c }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13846: GHC Panic: Visible type application + function type @(_ -> _)
by GHC 21 Jun '17

21 Jun '17

#13846: GHC Panic: Visible type application + function type @(_ -> _) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -XTypeApplications -ignore-dot-ghci GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Prelude> :t fmap @(_ -> _) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): repSplitAppTys w0_a1pF[tau:2] w0_a1pH[tau:2] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:809:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}} Doesn't happen with other types it seems, probably something to do with levity polymorphism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13827: "What AbsBinds means" is a pretty confusing doc comment
by GHC 20 Jun '17

20 Jun '17

#13827: "What AbsBinds means" is a pretty confusing doc comment -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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 the note in https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/ghc-8.0.1/src/… named "What AbsBinds means". It seems like the example refers variables that are not defined (at least in the example), for example `gp`. Also, a bit more verbose text would be welcome (aka I have no idea what is going on). Thank you! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13681: Remove deprecated ForceSpecConstr
by GHC 20 Jun '17

20 Jun '17

#13681: Remove deprecated ForceSpecConstr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a note at the top of `SpecConstr` which says {{{ ToDo [Oct 2013] ~~~~~~~~~~~~~~~ 1. Nuke ForceSpecConstr for good (it is subsumed by GHC.Types.SPEC in ghc-prim) 2. Nuke NoSpecConstr }}} `ForceSpecConstr` still exists so this ticket is to track the progress made on removing it. It isn't clear to me why it is ok to get rid of `NoSpecConstr` (which prevents SpecConstr firing) either. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13681> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7198: New codegen more than doubles compile time of T3294
by GHC 20 Jun '17

20 Jun '17

#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): The above fix almost halves the allocation when compiling T3294 (we're back to the level from 2012/2013 according `perf/compiler/all.T`), so I was thinking about closing this as fixed. Simon, are you ok with this? (or should we look into something more?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 20 Jun '17

20 Jun '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I agree with nakaji-dayo here. Emitting a warning upon every use of `quux` feels like the wrong design choice. To address goldfire's point above: > We want to be able to have fields such as `quux` that are used only with some (but not all) constructors of a type I agree. I think a reasonable design would be: * Introduce a flag for this purpose (proposal: `-Wpartial-records`) * If the flag is enabled and you define a partial record selector (e.g., `data A = B1 { b :: Int } | B2 { b :: Int, wat :: Char }`, emit a warning of the definition site (and only the definition site). * One can disable this warning by prefixing the partial record selector with an underscore (e.g., `data A = B1 { b :: Int } | B2 { b :: Int, _wat :: Char }`). This should allow you to use the partial record for scenarios where it's handy, but it also gives a visual indication that something is fishy about that function. A separate question is if this flag should be implied by `-Wall`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0