#7684: cgrun071 segfaults
----------------------------------+----------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: infoneeded
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 Johan Tibell <johan.tibell@…>):
In [changeset:"ad9bf96815cb5a9bb4acc51c99eff20be3e50da3/ghc-prim"]:
{{{
#!CommitTicketReference repository="ghc-prim"
revision="ad9bf96815cb5a9bb4acc51c99eff20be3e50da3"
Make argument types in popcnt.c match declared primop types
On 64-bit Mac OS, gcc 4.2 (which comes with Xcode 4.6) generates code
that assumes that an argument that is smaller than the register
it is passed in has been sign- or zero-extended. But ghc thinks
the types of the PopCnt*Op primops are Word# -> Word#, so it passes
the entire argument word to the hs_popcnt* function as though it was
declared to have an argument of type StgWord. Segfaults ensue.
The easiest fix is to sidestep all this zero-extension business
by declaring the hs_popcnt* functions to take a whole StgWord (when their
argument would fit in a register), thereby matching the list of primops.
Fixes #7684.
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:52>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7684: cgrun071 segfaults
----------------------------------+----------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: infoneeded
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 chatted a bit with rwbarton about the semantics of these primops. My
intention is that all the primops work on all input sizes (much like the
underlying assembly instruction) and the difference is just the number of
bit we count. The code implements this behavior correctly, if it weren't
for LLVM misbehaving. The reason I implemented the primops this way is
that I wanted to avoid the narrowing.
This means that even if we had a `Word8#` type, the primops would still
operate on a `Word#`. Does that make sense?
If so the right fix is to work around the LLVM bug in `popcnt.c`.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:51>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7684: cgrun071 segfaults
----------------------------------+----------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: infoneeded
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):
gcc-llvm I think is the apple version of dragonegg, which uses the proper
GCC frontend, but does the code gen with llvm
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:50>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7684: cgrun071 segfaults
----------------------------------+----------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: infoneeded
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 think I've figured it out. I've installed the CLI tools that came with
XCode 4.6. Here's the gcc that's included:
{{{
$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
5658) (LLVM build 2336.11.00)
}}}
So this is a LLVM-based GCC (i.e. clang). This GCC indeed produces
incorrect code for `popcnt.c`:
{{{
#!asm
_hs_popcnt8:
Leh_func_begin1:
pushq %rbp
Ltmp0:
movq %rsp, %rbp
Ltmp1:
leaq _popcount_tab(%rip), %rax
movzbl (%rdi,%rax), %eax
popq %rbp
ret
}}}
Note how the argument is not zero extended when it's used to compute and
address in `_popcount_tab`.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:49>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7684: cgrun071 segfaults
----------------------------------+----------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: infoneeded
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):
Replying to [comment:42 simonmar]:
> Well, one bug is that in `emitPopCntCall` we don't cast the argument to
the correct width.
I don't think it should.
The `MO_PopCnt` `MachOp` that's emitted by `emitPopCntCall` also takes the
width as an argument. The reason we pass the width all the way down to the
native and LLVM code generators is to avoid doing any narrowing, as we can
emit a `popcnt` instruction that looks at just part of the word (e.g.
`popcnt %ax,%ax`).
If we end up not using the the dedicated instruction, and we're using GCC
4.2 which doesn't do the narrowing correctly, then we'd have to do the
narrowing ourselves before calling the C fallback.
I think we have two choices in working around the buggy behavior of GCC
4.2:
1. Change the function prototype as rwbarton suggested.
2. Do some narrowing in the native code generator before emitting the
call to the C function.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:46>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8693: dyn way broken on powerpc
----------------------------+----------------------------------------
Reporter: trommler | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.7
Keywords: | Operating System: Linux
Architecture: powerpc | Type of failure: Building GHC failed
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
----------------------------+----------------------------------------
Building GHC with dynamic enabled I see lots of the following errors on
powerpc (32 bit):
{{{
[ 1679s] /tmp/ghc19669_0/ghc19669_6.s: Assembler messages:
[ 1679s]
[ 1679s] /tmp/ghc19669_0/ghc19669_6.s:39625:0:
[ 1679s] Error: operand out of range (0x000000000000b700 is not
between 0xffffffffffff8000 and 0x0000000000007fff)
...
[ 1679s] /tmp/ghc19669_0/ghc19669_6.s:43936:0:
[ 1679s] Error: operand out of range (0x0000000000008018 is not
between 0xffffffffffff8000 and 0x0000000000007fff)
[ 1679s] make[1]: *** [libraries/time/dist-
install/build/Data/Time/Format.o] Error 1
[ 1679s] make[1]: *** Deleting file `libraries/time/dist-
install/build/Data/Time/Format.o'
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8693>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
