- ghc-tickets - Haskell.org

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

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new 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 tibbe): I don't want to fix anything without understanding what the problem is first. There's nothing wrong with {{{ extern StgWord hs_popcnt8(StgWord8 x); }}} so why is the compiler doing the wrong thing? Aside: if we can one day fix Word8 to actually use a Word8# behind the scene changing the signature of the C function would be wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new 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): In the #7383 "promote arguments" patch, shouldn't the new line 2060 read {{{ let prom_args = map (maybePromoteCArg dflags W64 {- not W32 -}) args }}} But anyways, I can't see why the code generator would think the argument of the `MO_PopCnt W8` operation is an 8-bit quantity—it comes from a Haskell `Word#`, and the type of the `popCnt8#` primop is `Word# -> Word#`. So we shouldn't expect the "promote arguments" patch to do anything here. Can't we just fix this by changing the definition of `hs_popcnt8` from {{{ extern StgWord hs_popcnt8(StgWord8 x); StgWord hs_popcnt8(StgWord8 x) { return popcount_tab[(unsigned char)x]; } }}} to {{{ extern StgWord hs_popcnt8(StgWord x); StgWord hs_popcnt8(StgWord x) { return popcount_tab[(unsigned char)x]; } }}} (and the same for hs_popcnt16, etc.)—then everybody will think that the argument to `hs_popcnt8` is a word rather than a single byte, and gcc 4.2 will be forced to output the same code as gcc 4.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new 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 carter): @leroux, could you paste that assembly as a Gist on github? Dropbox is 404ing for everyone, and makes it harder to have a persistent copy for everyone -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new 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 leroux): Here's the disassembly and the backtrace so that you can find the caller. [https://dl.dropboxusercontent.com/u/21651328/cgrun071-gcc42-fails.S cgrun071 disassembly] (Can't attach it here because it's ~20MB) {{{ (gdb) bt #0 0x000000010027f74b in hs_popcnt8 () #1 0x000000010000475a in c1gz_info () Previous frame inner to this frame (gdb could not unwind past this frame) }}} Hope that helps. Also, I probably should have included this in my last comment. {{{ (gdb) run Starting program: /Users/leroux/Dropbox/src/ghc/ghc- validate/testsuite/tests/codeGen/should_run/cgrun071 Reading symbols for shared libraries +++.............................. done OK Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x000000010027f74b in hs_popcnt8 () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new 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): (According to [http://gcc.gnu.org/ml/gcc/2013-01/msg00447.html this discussion with an editor of the System V x86_64 ABI], a callee must NOT assume that its arguments have been sign-/zero-extended to fill their registers. So the gcc 4.2 `hs_popcnt8` is wrong, and the gcc 4.8 `hs_popcnt8` is right. However, pointing the finger at a widely-installed compiler is not very helpful when we could presumably fix the issue by doing the zero-extension in ghc instead.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 06 Sep '13

06 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184, 8235 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by refold): Replying to [comment:50 parcs]: > OK, done. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

06 Sep '13

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new 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): I don't understand how the first 8 or so lines of gdb output are consistent with the rest, so I'm going to assume that gdb was temporarily confused. The `info registers` output looks much more plausible. Replying to [comment:15 simonmar]: > The native code generator is supposed to emit code to mask out the extra bits. If it isn't doing that, that's a bug. See commit 085e8145f63c8f42d8bc19cd3cff52b8cd5b6455 Going by leroux's `info registers` output, it sure looks like it isn't masking them out, since the argument register `rdi` is `0x98b7fa5e6c84f828`. From the assembly diff I see that gcc 4.8 outputs code to do the masking in the callee (`movzbl %dil, %edi`) where gcc 4.2 does not. Oddly the System V x86_64 ABI doesn't seem to specify whether arguments in registers that are smaller than the register size should be masked/sign-extended by the caller, but I gather that we are working under the assumption that they should be (which is consistent with the 386 ABI). leroux, could you attach the entire `cgrun071.S` disassembly output? Or if it's very large, at least the disassembly of the function which calls `hs_popcnt8`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 06 Sep '13

06 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184, 8235 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:49 refold]: > Right now this is mostly for convenience - to enable supporting both the master > version of GHC 7.7 and the parmake branch. In the future this will be less > important - unless GHC HQ opts to disable parallel --make on some platforms for > some reason. > > Implementing this is trivial: just add a `("Supports parallel --make", "YES")` > tuple to the list returned by compiler/main/DynFlags.compilerInfo. I can write a > patch myself if you want. OK, done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7980: runghc dies silently when given large numbers of arguments. Compiled code does not.
by GHC 06 Sep '13

06 Sep '13

#7980: runghc dies silently when given large numbers of arguments. Compiled code does not. ------------------------------------------------+-------------------------- Reporter: totherme | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I'm going to mark this as fixed since `runghc` no longer dies silently when given too many arguments. It's a little annoying that because `runghc` packs its argument list into a single argument to `ghc`, the effective maximum argument list size for `runghc` is quite a lot smaller than it would be for the compiled program, because of the two different limits in Linux. But I'm going to chalk that up to an oddity of Linux; there would always be *some* difference in maximum argument list size. If this really bothers someone, they can open a new ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7980#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8239: Wrong link in docs
by GHC 06 Sep '13

06 Sep '13

#8239: Wrong link in docs ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- trivial mistake, see https://github.com/nomeata/ghc/compare/fixlink and pull with {{{ git pull https://github.com/nomeata/ghc fixlink }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5