August 2016 - ghc-tickets

[GHC] #9517: hp2ps generates invalid postscript file
by GHC 07 Aug '16

07 Aug '16

#9517: hp2ps generates invalid postscript file -----------------------------+---------------------------------- Reporter: JamesM | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------+---------------------------------- Some of the outputs have a name such as foo(...). However, the postscript generation does not add an extra closing parenthesis after the foo(...). Example from attachment on line 410. ((447)modifyEdge.newEdges.(...) show This should presumably be: ((447)modifyEdge.newEdges.$...$) show Output from ps2pdf: Error: /syntaxerror in -file- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1163/1684(ro)(G)-- --dict:0/20(G)-- --dict:79/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 40721 GPL Ghostscript 9.07: Unrecoverable error, exit code 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes
by GHC 07 Aug '16

07 Aug '16

#12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #7437 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This module compiles with GHC 8: {{{ {-# LANGUAGE DefaultSignatures #-} -- {-# LANGUAGE AllowAmbiguousTypes #-} -- Not required with GHC 8.0.1. module T12151 where class Put a where put :: a default put :: t -- This should be `a` instead of `t` put = undefined }}} GHC 7.10 required `AllowAmbiguousTypes`, to defer the ambiguity check to use sites. (Example extracted from the description of #7437) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code
by GHC 06 Aug '16

06 Aug '16

#9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In an attempt to close #4210 the LLVM code generator's mangler was modified in ed67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables. Unfortunately, this mangling was a simple text replacement of `@function` to `@object` in the assembler produced by LLVM and made no attempt to distinguish `.type` directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of `"@function"` in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to `"@object"` in the produced object. Hilarity ensues. This can be demonstrated by the simple test `main = putStrLn "@function"`, which prints `@object` in the affected releases (7.8.1 through 7.8.3 thusfar). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 06 Aug '16

06 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * differential: D2443 => Phab:D2443 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 06 Aug '16

06 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): D2443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * status: new => patch * differential: => D2443 Comment: I uploaded a diff which includes my changes. I tried to integrate unrolling the unboxed tuples in the bytecode generator now, which seems to work, but may miss some cases. There may be some points which could be done in a better way, so feel free to point them out and I will change them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 05 Aug '16

05 Aug '16

#5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5567#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12405: Add expansions of abbreviated type names in documentation
by GHC 05 Aug '16

05 Aug '16

#12405: Add expansions of abbreviated type names in documentation -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: GHC API | 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: -------------------------------------+------------------------------------- Type names are often abbreviated for programmer convenience, but they make using the GHC API much harder for newcomers. I would like to add some documentation to these declarations for ease of use. For example: {{{#!hs type LHsDecl id }}} -> {{{#!hs -- | Located Haskell Declaration type LHsDecl id }}} as opposed to {{{#!hs -- | Left-Hand side Declaration type LHsDecl id }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5834: Allow both INLINE and INLINABLE for the same function
by GHC 04 Aug '16

04 Aug '16

#5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * status: closed => new * resolution: invalid => Comment: Mpickering, I think bgamari's ask/clarification edit of the ticket : namely the ability to inline saturated applications and specialize unsaturated use sites. And that we currently can't quite express that? I may be interpreting this incorrectly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5834#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12462: Cannot add directories with colon to include path
by GHC 04 Aug '16

04 Aug '16

#12462: Cannot add directories with colon to include path -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | 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: -------------------------------------+------------------------------------- {{{ ezyang@sabre:~$ ls f:g A.hi A.hs A.o ezyang@sabre:~$ ghc-8.0 --make A -if:g <no location info>: error: module ‘A’ is a package module ezyang@sabre:~$ ghc-8.0 --make A -if\:g <no location info>: error: module ‘A’ is a package module ezyang@sabre:~$ ghc-8.0 --make A -if\\:g <no location info>: error: module ‘A’ is a package module }}} The problem is that the colon is interpreted as a path separator.\ Of course, colons break everything forever, so you shouldn't use them. But it is still a bit unsatisfactory. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12462> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5834: Allow both INLINE and INLINABLE for the same function
by GHC 04 Aug '16

04 Aug '16

#5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => invalid Comment: I think there is some confusion here. From my understanding the `INLINABLE` pragma causes the unfolding to be added to the interface file and in addition `INLINE` makes the cost very cheap to encourage the actual inlining. If this is wrong then someone please open the ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5834#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0