October 2017 - ghc-tickets

[GHC] #14402: Compiler hangs - UdecidableInstances
by GHC 30 Oct '17

30 Oct '17

#14402: Compiler hangs - UdecidableInstances -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Normally I wouldn't consider GHC going into infinite loop when `UndecidableInstances` is enabled as a bug, because compiler still terminates unless maybe something like `-freduction-depth=0` is supplied. That is not the case with this few lines of Haskell, as they cause GHC to hang for good and even made it use up all of my 32Gb of RAM, while I was looking the other way. Seems a bit unusual for GHC, so here is a record of it as a bug report. Compiling with `-v3` stops here: {{{ [1 of 1] Compiling Nested ( src/Nested.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.2/build/Nested.o ) *** Parser [Nested]: !!! Parser [Nested]: finished in 1.03 milliseconds, allocated 0.566 megabytes *** Renamer/typechecker [Nested]: }}} Compilation with GHC 8.0.2 goes through just fine. Although, I did encounter it hanging as part of a much bigger picture because of the same few lines of code. Coming up with a small reproducible example is much harder for that case as it hangs while compiling the test suite, instead of the offending module. In order to replicate the problem, the included code has to be compiled as a library rather than as an executable. Using `stack build --install-ghc` should do it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14402> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14400: Make :sprint, :print, and :force work with cyclical structures
by GHC 30 Oct '17

30 Oct '17

#14400: Make :sprint, :print, and :force work with cyclical structures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- {{{ > t = "hi" : t > :force t }}} never completes, because GHC races around and around in a loop forever. It would seem better to keep a hashset of nodes that have already been visited to avoid getting stuck, and print out a reasonable representation of the graph. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13945: make install fails when registering packages
by GHC 30 Oct '17

30 Oct '17

#13945: make install fails when registering packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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: -------------------------------------+------------------------------------- In the final part of installation when packages are registered, the following command fails {{{ "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg" "/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708" '' '/home/pgrads/mp16005/linux/installed-ghc' '/home/pgrads/mp16005/linux /installed-ghc/lib/ghc-8.2.0.20170708' '/home/pgrads/mp16005/linux /installed-ghc/share/doc/ghc-8.2.0.20170708/html/libraries' NO }}} with the following output {{{ Registering library for ghc-prim-0.5.0.0.. ghc-cabal: '/home/pgrads/mp16005/linux/installed-ghc/lib/ghc-8.2.0.20170708/bin/ghc- pkg' exited with an error: ghc-pkg: Couldn't open database /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d for modification: {handle: /home/pgrads/mp16005/linux/installed- ghc/lib/ghc-8.2.0.20170708/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) }}} It might be something to do with the permissions I have on my machine but I used to be able to install ghc if I gave it a suitable prefix other than `/usr/local`. Here is the call stack from the crash if that's useful. {{{ CallStack (from HasCallStack): die', called at libraries/Cabal/Cabal/Distribution/Simple/Program/Run.hs:142:7 in main:Distribution.Simple.Program.Run runProgramInvocation, called at libraries/Cabal/Cabal/Distribution/Simple/Program/HcPkg.hs:167:5 in main:Distribution.Simple.Program.HcPkg register, called at libraries/Cabal/Cabal/Distribution/Simple/GHC.hs:1709:5 in main:Distribution.Simple.GHC registerPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:350:14 in main:Distribution.Simple.Register registerPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:172:16 in main:Distribution.Simple.Register registerAll, called at libraries/Cabal/Cabal/Distribution/Simple/Register.hs:125:5 in main:Distribution.Simple.Register register, called at libraries/Cabal/Cabal/Distribution/Simple.hs:770:10 in main:Distribution.Simple defaultRegHook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:584:20 in main:Distribution.Simple regHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in main:Distribution.Simple.UserHooks regHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:120:5 in main:Distribution.Simple.UserHooks cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:452:38 in main:Distribution.Simple cmd_hook, called at libraries/Cabal/Cabal/Distribution/Simple.hs:469:4 in main:Distribution.Simple hookedActionWithArgs, called at libraries/Cabal/Cabal/Distribution/Simple.hs:451:5 in main:Distribution.Simple hookedAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:430:5 in main:Distribution.Simple registerAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:184:50 in main:Distribution.Simple defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:133:28 in main:Distribution.Simple defaultMainWithHooksArgs, called at utils/ghc-cabal/Main.hs:214:6 in main:Main }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #13825: Allow multiple constructor fields occupy the same word
by GHC 30 Oct '17

30 Oct '17

#13825: Allow multiple constructor fields occupy the same word -------------------------------------+------------------------------------- Reporter: michalt | Owner: (none) 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: -------------------------------------+------------------------------------- The main goal is to reduce the overhead of things like: {{{#!hs data Bloated = Bloated {-# UNPACK #-} !Word8 {-# UNPACK #-} !Int8 {-# UNPACK #-} !Bool }}} Assuming 64-bit architecture, currently those fields will take 8 bytes each! So for this example we'd need: 8 bytes for header + 3 * 8 bytes for fields = 32 bytes. But we should be able to pack the fields into a single word (a word is 8 bytes and each field really only needs 1 byte) for a total of 16 bytes (8 bytes header + 8 bytes for fields, with the 5 bytes being "overhead" due to heap alignment). My understanding is that we need a few things to make this happen: - Ability to refer to fields that are packed into a single word (currently everything in GHC assumes that each field occupies a single word). Simon Marlow started working on this in https://phabricator.haskell.org/D38 - Introduce primitives like `Word8#`, `Int8#`, ... (currently `WordX` and `IntX` are defined as wrappers of `Word#` and `Int#` respectively) and change `WordX`/`IntX` definitions to use those primitives. - Figure out what to do with `Bool` (should it be just `Word8#`? should we have `Bool#`?) and change its definition (using pattern synonyms for `True`/`False`) Some additional info: - Thread on ghc-devs: https://mail.haskell.org/pipermail/ghc- devs/2017-June/014304.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 29 Oct '17

29 Oct '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * status: closed => new * version: 7.4.1 => 8.3 * resolution: fixed => * milestone: 7.6.2 => Comment: I've encountered this error while building ghc; let me know if it would be more appropriate to create a new ticket. When building ghc, booting with ghc-8.2.1, with the following build.mk: {{{ BuildFlavour = prof ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcStage2HcOpts += -fprof-auto -fno-prof-count-entries }}} I get the following error while linking libHSghc-8.3.p_a: {{{ /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(HscMain.p_o):s1afa_info: error: undefined reference to 'ghc_CoreToStg_coreToStgzipgmzq_Cq7W_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(StgLint.p_o):sort_info: error: undefined reference to 'ghc_Type_newTyConInstRhszirhs_ChfI_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(StgLint.p_o):soru_info: error: undefined reference to 'ghc_Type_newTyConInstRhszitvs_ChfH_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(StgLint.p_o):sorC_info: error: undefined reference to 'ghc_Type_newTyConInstRhszirhs_ChfI_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(StgLint.p_o):sorD_info: error: undefined reference to 'ghc_Type_newTyConInstRhszitvs_ChfH_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(RtClosureInspect.p_o):sMUb_info: error: undefined reference to 'ghc_Type_newTyConInstRhszirhs_ChfI_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(RtClosureInspect.p_o):sMUd_info: error: undefined reference to 'ghc_Type_newTyConInstRhszitvs_ChfH_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(TcForeign.p_o):sy5L_info: error: undefined reference to 'ghc_Type_newTyConInstRhszirhs_ChfI_cc' /home/doug/ghc- dev/validate/compiler/stage2/build/libHSghc-8.3_p.a(TcForeign.p_o):sy5W_info: error: undefined reference to 'ghc_Type_newTyConInstRhszitvs_ChfH_cc' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14399: NCG: dead code stripping prevention wastes space
by GHC 29 Oct '17

29 Oct '17

#14399: NCG: dead code stripping prevention wastes space -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: low-hanging | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Symptom Consider this NCG-generated code: {{{ .long _T5001a_zdp1Comorphism_info - _T5001a_zdp1Comorphism_info_dsp .data .align 3 .align 0 .globl _T5001a_mapzusentence_closure _T5001a_mapzusentence_closure: .quad _T5001a_mapzusentence_info .text .align 3 _T5001a_mapzusentence_info_dsp: .align 3 .quad 4294967301 .quad 0 .quad 14 .globl _T5001a_mapzusentence_info _T5001a_mapzusentence_info: }}} There is an inert `.long` at the end of each Cmm procedure. This fills up precious instruction cache and wastes space. = Potential solutions Some ideas to improve the situation follow: 1. Move all those longs to a "table" at the end of the compilation unit (idea by Henning Thielemann), 2. coalesce the relocation into the previous instruction by explicitly calculating the opcode (craziness by me), 3. coalesce the relocation into the following info table like this: {{{ .quad 4294967301 - 24 + _T5001a_zdp1Comorphism_info - _T5001a_zdp1Comorphism_info_dsp }}} 4. Instead of exporting `_T5001a_mapzusentence_info` export `_T5001a_mapzusentence_info_dsp` and jump/call `_T5001a_mapzusentence_info_dsp + 24` instead. (Idea by Henning Thielemann.) == Discussion 1. Improves instruction cache only 2. hard to implement, leads to ugly assembly 3. wastes a long per compilation unit (at the end), needs a new state in the assembly writer 4. leads to unintuitive (ugly?) assembly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13038: implementation of Modus ponens and Modus tollens
by GHC 29 Oct '17

29 Oct '17

#13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Can we have in Prelude - Booleans, Modus ponens and Modus tollens implemented? Or in another module? reminder:[[BR]] P is a proposition and v(p) is the logic value of P.[[BR]] P is true, v(P) = 1[[BR]] P is false, v(P) = 0[[BR]] P -> Q is always true in propositional logic. Modus ponens:[[BR]] v(P) = 1[[BR]] v(P -> Q) = 1[[BR]] v(Q) = 1[[BR]] v(P) and v(P -> q) are premiss, v(q) is the conclusion.[[BR]] or in a more general form[[BR]] P : X is A[[BR]] P -> Q : A -> B[[BR]] Q : X is B[[BR]] Modus tollens:[[BR]] v(Q) = 0[[BR]] v(P -> Q) = 1[[BR]] v(P) = 0[[BR]] v(Q) and v(P -> Q) are premiss, v(P) is the conclusion.[[BR]] or in a more general form[[BR]] not Q : X is not B[[BR]] P -> Q : A -> B[[BR]] not P : X is not A[[BR]][[BR]] As well as using the numbers 0 and 1 for the respective values false and true, we'll use the letters F for False and T for True.[[BR]] We are always:[[BR]] v(F) = 0[[BR]] v(T) = 1[[BR]] v(P -> Q) = 1[[BR]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14393: Levity-polymorphic join point crashes 8.2
by GHC 28 Oct '17

28 Oct '17

#14393: Levity-polymorphic join point crashes 8.2 -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.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 program crashes both GHC 8.0 and 8.2 {{{ {-# LANGUAGE ViewPatterns, PatternSynonyms #-} module Foo where data PrimOp = AddOp | Add2Op | OtherOp | BotherOp data Expr = Var PrimOp | App Expr Expr | BApp [Expr] | BOp Expr Expr | L Integer pattern BinOpApp :: Expr -> PrimOp -> Expr -> Expr pattern BinOpApp x op y = Var op `App` x `App` y pattern (:+:) :: Expr -> Expr -> Expr pattern x :+: y <- BinOpApp x (isAddOp -> True) y isAddOp :: PrimOp -> Bool isAddOp AddOp = True isAddOp Add2Op = True isAddOp _ = False pattern (:++:) :: Integer -> Expr -> Expr pattern l :++: x <- (isAdd -> Just (l,x)) isAdd :: Expr -> Maybe (Integer,Expr) {-# INLINE isAdd #-} isAdd e = case e of L l :+: x -> Just (l,x) x :+: L l -> Just (l,x) _ -> Nothing }}} Reason: the matching function, generated by the pattern synonym `:++:`, has a levity-polymorphic join point. 8.0 has a Lint Error. 8.2 crashes with {{{ (GHC version 8.2.1.20171024 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (r_a1kX :: TYPE rep_a1kW) rep_a1kW 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/simplStg/RepType.hs:360:5 in ghc:RepType runtimeRepPrimRep, called at compiler/simplStg/RepType.hs:342:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:305:18 in ghc:RepType typePrimRep, called at compiler/simplStg/RepType.hs:128:19 in ghc:RepType }}} I think this is just #13394, comment:4 again. It was fixed in comment:5 of that ticket, but the fix has not yet been transferred to 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14397: For type error involving inferred types, show source of the type
by GHC 28 Oct '17

28 Oct '17

#14397: For type error involving inferred types, show source of the type -------------------------------------+------------------------------------- Reporter: max630 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider the code: {{{#!hs a = 42 b = a . "hello" }}} The type Error is (ghc-8.2.1): {{{ TestTypes.hs:3:5: error: • Couldn't match expected type ‘b0 -> c’ with actual type ‘Integer’ • In the first argument of ‘(.)’, namely ‘a’ In the expression: a . "hello" In an equation for ‘b’: b = a . "hello" • Relevant bindings include b :: a -> c (bound at TestTypes.hs:3:1) | 3 | b = a . "hello" | ^ TestTypes.hs:3:9: error: • Couldn't match expected type ‘a -> b0’ with actual type ‘[Char]’ • In the second argument of ‘(.)’, namely ‘"hello"’ In the expression: a . "hello" In an equation for ‘b’: b = a . "hello" • Relevant bindings include b :: a -> c (bound at TestTypes.hs:3:1) | 3 | b = a . "hello" | ^^^^^^^ }}} Actually, the real mistake may be in line 1, where `a` is inferred as of type `Integer`, while it probably was not meant to. But that location is not reported to the error. As you can guess, in real code location where the unexpected type is inferred for a binding is not that obvious to find. Suggestion: track locations where bindings' types are inferred, and in case of type error involvin the bindings, add them to the "Relevant bindings" section, or otherwise show it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14397> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD
by GHC 27 Oct '17

27 Oct '17

#13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `purescript-0.10.7` fails to build with GHC HEAD at the moment due to an apparent regression in the way pattern synonyms and overloaded strings interact. Here is a simplified example: {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE PatternSynonyms #-} module Bug where import Data.ByteString newtype ProperName = ProperName { runProperName :: ByteString -- purescript actually uses the Text type, but this works -- just as well for the purposes of illustrating the bug } newtype ModuleName = ModuleName [ProperName] pattern TypeDataSymbol :: ModuleName pattern TypeDataSymbol = ModuleName [ProperName "Type",ProperName "Data", ProperName "Symbol"] }}} Compiling this with GHC 7.10.3 or 8.0.2 works without issue. In GHC HEAD, if you compile this with optimization enabled, it'll trigger a GHC panic: {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 -O1 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170303 for x86_64-unknown-linux): isUnliftedType r_a28T :: TYPE rep_a28S Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1961:10 in ghc:Type }}} The presence of optimization is crucial for reproducing this bug, as compiling it with `-O0` does not trigger the panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7