September 2013 - ghc-tickets

Re: [GHC] #7684: cgrun071 segfaults
by GHC 09 Sep '13

09 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Well, one bug is that in `emitPopCntCall` we don't cast the argument to the correct width. The `-dcmm-lint` should catch it, because the argument width isn't the same as the primop is expecting, but the Cmm linter doesn't check the arguments of prim calls (that's another bug). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 09 Sep '13

09 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by rwbarton): Replying to [comment:40 simonmar]: > The patch is very likely to be papering over the problem rather than fixing it. While the primop does take a Word# (because there's no `Word8#`), the MachOp `MO_PopCnt` really does take an 8-bit value when it is generated by the 8-bit version of the primop. How so? Of course we want it to be true, but I don't see any place where GHC is aware of this. Let's trace through the compilation of a PopCnt8Op primop versus a PopCnt16Op primop. The only place where these are treated differently is in `emitPrimOp`, which calls `emitPopCntCall` with an argument of `W8` in the former and `W16` in the latter case. `emitPopCntCall` only uses that argument as a field of the `MO_PopCnt` constructor. It doesn't do any kind of cast or assertion on the size of its argument. In the native code generator, the field of `MO_PopCnt` is only used to build the name of the C function to call (assuming no SSE). So, it's unsurprising to me that GHC does not, for example, narrow the argument to `hs_popcnt8` to 8 bits, but narrow the argument to `hs_popcnt16` to 16 bits. Maybe you think some part of the above is a bug, and prefer to fix the problem there. I didn't want to guess where the bug was, so I proposed this patch to the C implementation to match the calling convention used by code generator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 09 Sep '13

09 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by simonmar): @ezyang: patches look good to me, push away. It'll be great to have this fixed, thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 09 Sep '13

09 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): The patch is very likely to be papering over the problem rather than fixing it. While the primop does take a Word# (because there's no `Word8#`), the MachOp `MO_PopCnt` really does take an 8-bit value when it is generated by the 8-bit version of the primop. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8235: Race condition in IO manager
by GHC 09 Sep '13

09 Sep '13

#8235: Race condition in IO manager ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: 910 Related Tickets: | ------------------------------------+------------------------------------- === Race.hs {{{ #!haskell import GHC.Conc main :: IO () main = do setNumCapabilities 2 setNumCapabilities 1 setNumCapabilities 2 }}} === Command Line {{{ $ ghc-stage2 -threaded Race.hs [1 of 1] Compiling Main ( Race.hs, Race.o ) Linking Race ... $ while true; do ./Race; echo -n .; done ...............................Race: GHC.Event.Manager.loop: state is already Finished }}} It looks like there is a race condition in `GHC.Event.Thread.restartPollLoop` where a write to `emState` is snuck in between releasing the executing thread and -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #4983: Warning about redundant import is wrong when hiding identifiers in order to avoid export ambiguities
by GHC 08 Sep '13

08 Sep '13

#4983: Warning about redundant import is wrong when hiding identifiers in order to avoid export ambiguities -------------------------------------------------+------------------------- Reporter: Lemming | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: Resolution: wontfix | Version: 7.0.1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Lemming): Replying to [comment:4 simonpj]: > Well that would apply to any other redundant import too. I suppose we could replace "The import of M is redundant" by "You imported M but used nothing of it". Maybe that'd be an improvement, I'm not sure. I have thought about the question, whether "redundant import" and "you used nothing of it" are synonyms or not. I think they are not. "Redundant import" means you can omit the import. "You used nothing of it" means erm that you used nothing from the module. Usually these two statements coincide. But since Prelude is imported automatically this is a corner case where the two statements are different. "You used nothing of it" is true in both the regular case and this corner case, whereas "redundant import" is only true in the regular case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4983#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 08 Sep '13

08 Sep '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): What I'm remembering is this: commit 67157c5c25c8044b54419470b5e8cc677be060c3 {{{ Author: simonpj(a)microsoft.com <unknown> Date: Tue Nov 16 17:18:43 2010 +0000 Warn a bit less often about unlifted bindings. Warn when (a) a pattern bindings binds unlifted values (b) it has no top-level bang (c) the RHS has a *lifted* type Clause (c) is new, argued for by Simon M Eg x# = 4# + 4# -- No warning (# a,b #) = blah -- No warning I# x = blah -- Warning }}} Which should mean that the bindings that Happy uses (where bindings of type `Int#`) do not generate warnings. So is there a bug in the warning? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7925: ghc 7.4.2 builds with errors on Red Had Enterprise Linux 6
by GHC 08 Sep '13

08 Sep '13

#7925: ghc 7.4.2 builds with errors on Red Had Enterprise Linux 6 -----------------------------+------------------------------------ Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------+------------------------------------ Changes (by monoidal): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Thanks for the report. Unfortunately 7.4 is not maintained anymore; Haskell Platform now uses 7.6 and it's unlikely that even 7.6 will have another release; all efforts are focused at 7.8. If you can check newer versions (7.6 or HEAD) and find a failure can you report it at #5757? That ticket indicates the lib/Time failure is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7925#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 08 Sep '13

08 Sep '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Hang on a minute. I think we decided *not* to warn about these, which is why I removed the bangs from Happy. I'll need to search through my email and commit logs and find out what happened. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 08 Sep '13

08 Sep '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): I have made a pull request for happy here, and once/if `happy-1.18.11` is released with this change, we can move on this ticket: https://github.com/simonmar/happy/pull/8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0