Opened 3 years ago
Closed 3 years ago
#9886 closed bug (fixed)
PowerPC : Undefined reference to `__sync_fetch_and_xor_8'
Reported by: | erikd | Owned by: | erikd |
---|---|---|---|
Priority: | normal | Milestone: | 7.10.1 |
Component: | Compiler (CodeGen) | Version: | 7.11 |
Keywords: | Cc: | simonmar, erikd, slyfox | |
Operating System: | Unknown/Multiple | Architecture: | powerpc |
Type of failure: | Building GHC failed | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | ||
Wiki Page: |
Description
Compiling on PowerPC with git head (0c9c2d899e63b810), compile terminates with:
/home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_xor_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_and_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_nand_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_val_compare_and_swap_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_sub_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_add_8' /home/ghc-upstream/libraries/ghc-prim/dist-install/build/ libHSghcpr_FgrV6cgh2JHBlbcx1OSlwt-ghc7.9.20141214.so: undefined reference to `__sync_fetch_and_or_8'
Looks like some new primops that need to be implemented for powerpc.
Change History (14)
comment:1 Changed 3 years ago by
comment:2 Changed 3 years ago by
I believe we fixed this on x86 by requiring i686. Can't find the ticket right now.
Another alternative is to actually implement it in the PowerPC but modifying the native code generator. We could lock at the instruction sequence GCC output for these and also take a hint from the x86 implementation I wrote.
comment:4 Changed 3 years ago by
Owner: | set to erikd |
---|---|
Version: | 7.8.3 → 7.11 |
It seems that these __sync_fetch_*
function were used around gcc 4.4 but have been replaced in gcc 4.8 with a different set of functions __atomic_*
.
Working on a patch to sort this out.
comment:5 Changed 3 years ago by
Cc: | erikd added |
---|
comment:6 Changed 3 years ago by
For some reason GCC doesn't seem to have 64 bit versions of any of the atomic functions.
comment:7 Changed 3 years ago by
Bah, turns out it was a lack of the 64 bit versions of these that was the problem all along.
comment:8 Changed 3 years ago by
Cc: | slyfox added |
---|
comment:9 follow-up: 11 Changed 3 years ago by
It seems the 64 bit primpos are *only* needed on 32 bit architectures and then only for the native code generators. For x86 via the native code generator we needed #9346 as mentioned by @tibbe, but the arm backend did need anything because that omly compilers via LLVM.
That leaves PowerPC as the remaining 32 bit architecture with an NCG. However, if I hack the 64 bit primops like (for example) this:
StgWord64 hs_atomic_add64(volatile StgWord64 *x, StgWord64 val) { #if WORD_SIZE_IN_BITS == 32 printf ("%s : %s not implemented.\n", __FILE__, __func__) ; exit (1); #else return __sync_fetch_and_add(x, val); #endif }
then building the compiler runs to completion and futhermore, the one test for these atomic primops, testsuite/tests/concurrent/should_run/AtomicPrimops.hs
passes. It turns out this test operates on Int which on 32 bit platforms is a 32 bit value.
This makes me wonder if its worth the trouble of implementing these if they aren't used anywhere.
comment:10 Changed 3 years ago by
Summary: | Undefined reference to `__sync_fetch_and_xor_8' → PowerPC : Undefined reference to `__sync_fetch_and_xor_8' |
---|
comment:11 Changed 3 years ago by
Replying to erikd:
It seems the 64 bit primpos are *only* needed on 32 bit architectures and then only for the native code generators.
Correction, the 64 bit primops are *not* needed on 32 bit architectures because there is currently no way to call them from Haskell code.
comment:13 Changed 3 years ago by
Status: | new → merge |
---|
comment:14 Changed 3 years ago by
Milestone: | → 7.10.1 |
---|---|
Resolution: | → fixed |
Status: | merge → closed |
Merged (via bd785d101766a1207b8d27a45b6ae0bf83cd678a), thanks Erik.
There is a quick and *very* dirty hack to get GHC compiling here ( https://phabricator.haskell.org/D560#15871 ) but it doesn't actually fix the problem, just prevent the compile error.