September 2013 - ghc-tickets

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

07 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): Well, which compiler is doing the wrong thing? According to the x86_64 ABI, gcc 4.2 is doing the wrong thing, because when it generates code for `hs_popcnt8`, it assumes that the high 7 bytes of the argument register `%edi` are 0. The caller is not supposed to have to guarantee that, and gcc 4.8 does the right thing by masking off the high 7 bytes inside `hs_popcnt8`. ghc sees a primop `PopCnt8Op` of type `Word# -> Word#`, and given that, it is doing the right thing by taking the whole `Word#` value extracted from the argument to `popcnt8` (in `cgrun071`) and putting it in `%edi` before calling `hs_popcnt8`. I don't think ghc looks at the C prototype of functions that implement primops, does it? It just prepares the arguments for the call in registers or on the stack according to their Cmm sizes, and does a call to the symbol of the right name. Now, the combination of ghc passing a whole `Word#` and `hs_popcnt8` treating the argument as an `unsigned char` works out according to the x86_64 ABI since the intent is to compute the popcnt of the lowest byte. It doesn't work out if `hs_popcnt8` expects its argument to be zero- extended from 1 byte to 8 bytes like under gcc 4.2. Changing the declared argument type of `hs_popcnt8` to `StgWord` will make `popcnt.c` agree with the list of primops. Given that we can modify ghc but not gcc 4.2 this seems like the best solution for now. If `Word8#` becomes a thing, we can change the signature of `hs_popcnt8` back and also change the declared type of `PopCnt8Op` to `Word8# -> Word#`. As I understand things, the key is that those two declarations agree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:35> 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 07 Sep '13

07 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:41 rrnewton]: I'm not able to reproduce the cabal-install issues. I did the following: 1. checked out `ghc-parmake-gsoc` and install built ghc 2. installed cabal-install 1.18 via GHC 7.6.2 3. successfully ran the command {{{ cabal install --with-ghc=/home/patrick/code/ghc/inplace/bin/ghc-stage2 --reinstall HUnit async }}} 4. successfully ran the same command with and without `-j` and/or `--ghc- option="-j` Am I missing something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

07 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 07 Sep '13

07 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