- ghc-tickets - Haskell.org

[GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses
by GHC 11 May '15

11 May '15

#10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The RdrHsSyn.isFunLhs function has the following {{{#!hs isFunLhs e = go e [] where go (L loc (HsVar f)) es | not (isRdrDataCon f) = return (Just (L loc f, False, es)) go (L _ (HsApp f e)) es = go f (e:es) go (L _ (HsPar e)) es@(_:_) = go e es }}} The treatment of `HsPar` means that any parentheses around an infix function will be discarded. e.g. {{{#!hs (f =*= g) sa i = f (toF sa i) =^= g (toG sa i) }}} will lose the `(` before `f` and the closing one after `g` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10269> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10268: ApiAnnotations : quoted type variables missing leading quote
by GHC 11 May '15

11 May '15

#10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `HsOpTy` can be constructed for a promoted type operator, in which case it has the following form {{{ | btype SIMPLEQUOTE qconop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } | btype SIMPLEQUOTE varop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } }}} The SIMPLEQUOTE does not get an annotation, so cannot be reproduced via the API Annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10268> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10299: Inconsistent parsing of lifted list constructor
by GHC 11 May '15

11 May '15

#10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The notes for `HsType` explain that `'[]` should parse as a `HsExplicitListTy` but it currently parses as a `HsTyVar`. I think this shift-reduce conflict might be to blame? {{{#!hs state 432 contains 1 shift/reduce conflicts. atype -> SIMPLEQUOTE '[' . comma_types0 ']' (rule 318) sysdcon -> '[' . ']' (rule 613) Conflict: ']' (empty comma_types0 reudes) TODO: Why? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10277: ApiAnnotations : lexer discards comment close in nested comment
by GHC 11 May '15

11 May '15

#10277: ApiAnnotations : lexer discards comment close in nested comment -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When parsing a nested comment, such as {{{#!hs {- {- nested comment -} {-# nested pragma #-} -} }}} The lexer returns the comment annotation as {{{#!hs {- {- nested comment {-# nested pragma # -} }}} Restore the missing comment end markers in the annotation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10254: parser : the API annotation on opt_sig is being discarded
by GHC 11 May '15

11 May '15

#10254: parser : the API annotation on opt_sig is being discarded -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `opt_sig` production is defined as {{{ opt_sig :: { ([AddAnn],Maybe (LHsType RdrName)) } : {- empty -} { ([],Nothing) } | '::' sigtype { ([mj AnnDcolon $1],Just $2) } }}} It is used in the `alt` and `decl_no_th` productions, but neither of them add the returned annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10254> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10256: parser: API Annotations : squals does not annotate commas properly
by GHC 11 May '15

11 May '15

#10256: parser: API Annotations : squals does not annotate commas properly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `squals` production includes {{{ | squals ',' qual {% addAnnotation (gl $ head $ unLoc $1) AnnComma (gl $2) >> return (sLL $1 $> ($3 : unLoc $1)) } }}} The `AnnComma` should be attached to `(gl $ last $ unLoc $1)`, rather than the head. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by puffnfresh): @Fuuzetsu: I can reproduce that problem on GHC 7.10.1 but I just built a version of master and can not with that. Does that particular instance of non-determinism look fixed in master to you? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:77> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 10 May '15

10 May '15

#5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 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 michalt): * cc: michalt (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5567#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9929: New alias handling not compatible with LLVM 3.4
by GHC 08 May '15

08 May '15

#9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As reported by Joachim here: https://www.haskell.org/pipermail/ghc- devs/2014-November/007480.html, and it happens for me too. It seems to affect every program compiled with `-fllvm`; T5681 just happens to be the only such program in the normal test suite. Faced with the definitions {{{ @Main_zdwwork_info_itable$def = internal constant %Main_zdwwork_entry_struct<{ i64 add (i64 sub (i64 ptrtoint (i8* @S2ZH_srt to i64),i64 ptrtoint ( void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_zdwwork_info$def to i64)),i64 8), i64 4294967299, i64 0, i64 4294967311}>, section "X98A__STRIP,__me3", align 8 @Main_zdwwork_info_itable = alias i8* bitcast (%Main_zdwwork_entry_struct* @Main_zdwwork_info_itable$def to i8*) }}} LLVM 3.4 produced the assembly {{{ .type Main_zdwwork_info_itable,@object # @Main_zdwwork_info_itable .section .rodata,"a",@progbits ; note .rodata, not X98A__STRIP,__me3! .globl Main_zdwwork_info_itable .align 16 Main_zdwwork_info_itable: .quad (S2ZH_srt$def-Main_zdwwork_info$def)+8 .quad 4294967299 # 0x100000003 .quad 0 # 0x0 .quad 4294967311 # 0x10000000f .size Main_zdwwork_info_itable, 32 }}} At first I thought this was an LLVM bug, but after reading http://llvm.org/docs/LangRef.html#linkage-types I'm not sure; maybe the `internal` linkage type means that `@Main_zdwwork_info_itable$def` is just a constant value without any "identity", so the LLVM optimizer is free to drop it, merge it with another constant, or move it to another section? One workaround would be to use external linkage for these `foo_info_itable$def` symbols, and then if desired (to reduce symbol table size), strip out any `.global bar$def` statements in the LLVM mangler...? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9929> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10251: Bad rule generated in pathological cases
by GHC 08 May '15

08 May '15

#10251: Bad rule generated in pathological cases -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- George reports: I am also seeing this on ghc 7.10.1, not sure if this is another instance of this bug (#9160): {{{ cabal install bitmap [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, dist/build/Data/Bitmap/IO.o ) Data/Bitmap/IO.hs:1248:1: Warning: SPECIALISE pragma for non-overloaded function ‘myPlusPtr’ Data/Bitmap/IO.hs:1249:1: Warning: SPECIALISE pragma for non-overloaded function ‘myPlusPtr’ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule $fPixelComponentFloat3_X2Rc [$fPixelComponentFloat3_X2Rc] [$fPixelComponentFloat3_X2Rc] [] [] }}} But it's ''not'' #9160 at all. So I'm making a new ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5