This is triggered by JDK-8316961 that exposed 64-bit CASes for 32-bit Zero builds, but the same would happen with other uses:

```
Building target 'hotspot' in configuration 'build-all-zero-fastdebug-arm-linux-gnueabi-10'
/usr/lib/gcc-cross/arm-linux-gnueabi/10/../../../../arm-linux-gnueabi/bin/ld: /usr/lib/gcc-cross/arm-linux-gnueabi/10/libgcc.a(linux-atomic-64bit.o): in function `__sync_val_compare_and_swap_8':
(.text+0x528): multiple definition of `__sync_val_compare_and_swap_8'; /home/shade/trunks/jdk/build/build-all-zero-fastdebug-arm-linux-gnueabi-10/hotspot/variant-zero/libjvm/objs/os_linux_zero.o:/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:483: first defined here
collect2: error: ld returned 1 exit status
gmake[3]: *** [lib/CompileGtest.gmk:97: /home/shade/trunks/jdk/build/build-all-zero-fastdebug-arm-linux-gnueabi-10/hotspot/variant-zero/libjvm/gtest/libjvm.so] Error 1
gmake[2]: *** [make/Main.gmk:253: hotspot-zero-libs] Error 2
```
There is a separate definition of `__sync_val_compare_and_swap_8` in Zero code, I think to catch the linkage errors when libatomic does not provide the symbol. That hunk dates back to original integration of Zero in 2009. But in cases libatomic _does_ provide the definition, we clash.

The conservative way to go through this is to check whether `__sync_val_compare_and_swap_8` is already defined to unbreak most of the builds. Note just checking for symbol existence does not unbreak the platforms for which libatomic still does not provide symbol. From the upstream bug reports, I think at least PPC32 is one of those platforms. The cleaner way to achieve this would be to move from `__sync*` to `__atomic*` built-ins that should be available always: JDK-8320052. That would require deeper testing.