#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