October 2015 - ghc-tickets

[GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages
by GHC 02 Oct '15

02 Oct '15

#10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I've seen three different issues on Github about this: two in the stack repo for stack users, and one in the yesod repo for a cabal sandbox user: https://github.com/yesodweb/yesod/issues/1020 https://github.com/commercialhaskell/stack/issues/466 https://github.com/commercialhaskell/stack/issues/795 The problem comes down to this: Windows has a limit of 32k on the size of a command string, which can be tripped by GHC's link phase when using a large number of libraries. The ideal situation would be for GHC to have a different way of passing large argument lists to the linker; I don't know how feasible this is, but I wanted to open up a ticket before I started investigating myself in case others have seen this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10475: detabify User's Guide
by GHC 02 Oct '15

02 Oct '15

#10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The User's Guide .xml files use a fairly random-looking mix of tabs and spaces for indentation. Let's get rid of the tabs and then enforce their absence with git hooks. Why do this? See #10425; apparently tabs within programlisting elements are rendered as some number of spaces other than 8 in the PDF version (only!) I briefly tried to find other instances of the same issue, but there are thousands of tab characters in the User's Guide and I'm too lazy to try to find only the ones within programlisting elements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 02 Oct '15

02 Oct '15

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1282 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 02 Oct '15

02 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10925: GHC should inform where unknown identifiers originate whenever possible
by GHC 02 Oct '15

02 Oct '15

#10925: GHC should inform where unknown identifiers originate whenever possible -------------------------------------+------------------------------------- Reporter: hanshoglund | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: imports, | Operating System: Unknown/Multiple error messages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Assume I have a module Foo, using implicit imports and unqualified identifiers (minimalistic example, actual cases could have hundreds of imported modules). {{{ module Foo import Data.List foo = intersperse ... }}} If I decide to switch to explicit imports, I have two options. I could import Data.List as qualified, or add an explicit export list. In both cases the origin of 'intersperse' will be unambiguous. If I choose qualified imports, GHC will helpfully tell me where all now unqualified identifiers originated. {{{ Not in scope: type constructor or class ‘intersperse’ Perhaps you meant one of these: ‘Data.List.intersperse’ }}} However, If I chose to add an explicit import list to the 'Data.List' import, I will have no such help. Again, if the number of imported modules is long, there is no obvious way to tell which module should have the explicit import by just looking at the code. On the other hand, as the above case shows GHC is obviously able to infer this. I can accomplish it by manually duplicating my import list, and adding a qualified import of every imported module, but this is a lot of manual work in modules with many imports. I suggest that for the purposes of error messages, top-level identifiers not in scope should be searched for in every module as if it had been imported qualified, and an error message akin to the following should be generated. Obviously, if the identifier is availble from a a qualified import, the above error message should take precedence. {{{ Not in scope: type constructor or class ‘intersperse’. It is available but not imported from the following modules: ‘Data.List.intersperse’ To bring the identifier into scope, import it from the one of the above modules, or use a qualified import. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10925> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10215: Optimizer has bugs regarding handling of -0.0
by GHC 02 Oct '15

02 Oct '15

#10215: Optimizer has bugs regarding handling of -0.0 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #9238 Differential Revisions: | -------------------------------------+------------------------------------- This is most likely related to https://ghc.haskell.org/trac/ghc/ticket/9238 Perhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this ticket can at least serve as a test-case. I observed this on 7.8.3; though I suspect the same holds in the just released 7.10.1 as well. For the following program: {{{#!hs testF :: Float -> Bool testF x = x == 0 && not (isNegativeZero x) testD :: Double -> Bool testD x = x == 0 && not (isNegativeZero x) main :: IO () main = do print $ testF (-0.0) print $ testD (-0.0) }}} If I compile with no optimizations, then I get the correct answers: {{{ $ /bin/rm -f a.hi a.o a; ghc -O0 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... False False }}} But if I turn optimizations on, then I get: {{{ $ /bin/rm -f a.hi a.o a; ghc -O2 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... True True }}} which is just plain wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7830: Error: operand out of range
by GHC 02 Oct '15

02 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"b29f20edb1ca7f1763ceb001e2bb2d5f2f11bec3/ghc" b29f20e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b29f20edb1ca7f1763ceb001e2bb2d5f2f11bec3" nativeGen PPC: fix > 16 bit offsets in stack handling Implement access to spill slots at offsets larger than 16 bits. Also allocation and deallocation of spill slots was restricted to 16 bit offsets. Now 32 bit offsets are supported on all PowerPC platforms. The implementation of 32 bit offsets requires more than one instruction but the native code generator wants one instruction. So we implement pseudo-instructions that are pretty printed into multiple assembly instructions. With pseudo-instructions for spill slot allocation and deallocation we can also implement handling of the back chain pointer according to the ELF ABIs. Test Plan: validate (especially on powerpc (32 bit)) Reviewers: bgamari, austin, erikd Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1296 GHC Trac Issues: #7830 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 02 Oct '15

02 Oct '15

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1282 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"bd41eb2ad9507d3f408e25c8dece61f389f11a2a/ghc" bd41eb2a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd41eb2ad9507d3f408e25c8dece61f389f11a2a" LLVM: Implement atomic operations in terms of LLVM primitives This fixes Trac #7883. This adds proper support for, * `MO_AtomicRMW` * `MO_AtomicWrite` * `MO_CmpXChg` Test Plan: Validate Reviewers: rrnewton, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1282 GHC Trac Issues: #7883 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10392: typo in Debug.Trace.traceShowM example
by GHC 02 Oct '15

02 Oct '15

#10392: typo in Debug.Trace.traceShowM example -------------------------------------+------------------------------------- Reporter: sebastian | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- s/traceMShow/traceShowM The documentation for Debug.Trace.traceShowM has an example, where the function is called traceMShow instead of the correct traceShowM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7253: Top-level bindings in ghci
by GHC 02 Oct '15

02 Oct '15

#7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: roshats Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1299 -------------------------------------+------------------------------------- Changes (by roshats): * owner: => roshats * differential: => Phab:D1299 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7253#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0