- ghc-tickets - Haskell.org

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

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

26 Oct '17

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.7 Resolution: fixed | 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): Phab:D4083 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, but I don't see an alternative here; we unfortunately only have so many options. There is already precedent within GHC to treat underscore- prefixed identifiers specially. I would much rather continue relying on that same convention than introduce yet more special cases. Ultimately the right solution here would likely be something like #602, but seeing as that's not on the horizon, I think we'll just have to make due with what we have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14377: false result in the addition
by GHC 26 Oct '17

26 Oct '17

#14377: false result in the addition -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Prelude> 1.1+2.2 3.3000000000000003 Prelude> 1.11+2.22 3.33 Prelude> 1.111+2.222 3.333 Prelude> 1.1111+2.2222 3.3333 Prelude> 1.11111+2.22222 3.33333 Prelude> 1.111111+2.222222 3.3333329999999997 Prelude> 1.1111111+2.2222222 3.3333333 Prelude> 1.11111111+2.22222222 3.33333333 Prelude> 1.111111111+2.222222222 3.333333333 Prelude> 1.1111111111+2.2222222222 3.3333333333 Prelude> 1.11111111111+2.22222222222 3.33333333333 Prelude> 1.111111111111+2.222222222222 3.333333333333 Prelude> 1.1111111111111+2.2222222222222 3.3333333333333 Prelude> 1.11111111111111+2.22222222222222 3.3333333333333304 Prelude> 1.111111111111111+2.222222222222222 3.333333333333333 }}} Given the other additions, three results can be improved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #14389: Improved results in GHCi during basic calculations
by GHC 26 Oct '17

26 Oct '17

#14389: Improved results in GHCi during basic calculations -------------------------------------+------------------------------------- Reporter: vanto | 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: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We can use GHCi as a calculator using {{{+}}}, {{{-}}}, {{{*}}}, {{{/}}}, {{{sin}}}, {{{cos}}}, and others. sometimes the result does not meet our expectations. for example if I calculate 3 + 2, the result is 5 and in line with our expectations. \\ {{{ Prelude> 3+2 5 }}} but sometimes it is not.\\ for the two examples below, please, can we have in GHCi a result other than the one given?\\ {{{ Prelude> exp(log(1000)-log(10)) 99.99999999999996 }}} can we have a result equal to {{{100}}}? \\ {{{ Prelude> 12*(1/3-1/4)-1 -2.220446049250313e-16 }}} can we have a result equal to {{{0}}}? \\ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14364: Reduce repetition in derived Read instances
by GHC 26 Oct '17

26 Oct '17

#14364: Reduce repetition in derived Read instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: #10980 #7258 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking at #7258 with tdammers, I noticed that 5000 of the 7000 terms that the `W2` module simplifies to are attributed to `$creadPrec`. In fact, much of this is repetition of the form, {{{#!hs (GHC.Read.expectP (Text.Read.Lex.Ident (GHC.CString.unpackCString# "field1"#))) (>> @ Text.ParserCombinators.ReadPrec.ReadPrec Text.ParserCombinators.ReadPrec.$fMonadReadPrec @ () @ DT (GHC.Read.expectP (Text.Read.Lex.Punc (GHC.CString.unpackCString# "="#))) (>>= @ Text.ParserCombinators.ReadPrec.ReadPrec Text.ParserCombinators.ReadPrec.$fMonadReadPrec @ Int @ DT (Text.ParserCombinators.ReadPrec.reset @ Int (GHC.Read.readPrec @ Int GHC.Read.$fReadInt)) (\ (a1_a1oe :: Int) -> >> @ Text.ParserCombinators.ReadPrec.ReadPrec Text.ParserCombinators.ReadPrec.$fMonadReadPrec @ () @ DT (GHC.Read.expectP (Text.Read.Lex.Punc (GHC.CString.unpackCString# ","#))) }}} Let's factor this pattern out into a `readField` helper in `GHC.Read`, {{{#!hs readField :: String -> ReadPrec a -> ReadPrec a readField fieldName readVal = do expectP (Ident fieldName) expectP (Punc "=") readVal {-# NOINLINE readField #-} }}} This will at least knock off a constant factor from the size of what should not be performance-critical code. We could also try folding the terminal "," into this, although then we would need to somehow handle the last field specially. This might not be worth it. Perhaps instead just factor out the comma case as well, {{{#!hs readComma :: ReadPrec () readComma = expectP (Punc ",") {-# NOINLINE readField #-} }}} It's unclear whether this is worth it, however. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9