There is a bug in current Zero on 32-bit platforms around 64-bit accesses. Access to `volatile long` goes all the way down to `Atomic::PlatformLoad<8>` / `Atomic::PlatformStore<8>` -> `Atomic::atomic_copy64`, which is implemented only for few architectures, and falls back to non-atomic read-write sequence:
https://github.com/openjdk/jdk/blob/9cce9fe06780aa095b3aabdfa421f376ca7bfd08/src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp#L174
This is easily reproducible with Linux Zero x86_32 and jcstress like:
```
$ build/linux-x86-zero-release/images/jdk/bin/java -jar jcstress-tests-all-20230612.jar -t accessAtomic.fields.volatiles.LongTest -tb 1m
...... [FAILED] o.o.j.t.accessAtomic.fields.volatiles.LongTest
Results across all configurations:
RESULT SAMPLES FREQ EXPECT DESCRIPTION
-1 39,131,094 15.14% Acceptable The value set by the actor thread. Observer sees the comp...
-4294967296 88 <0.01% Forbidden Other values are forbidden: atomicity violation.
0 219,340,811 84.86% Acceptable Default value for the field. Allowed to see this: data race.
```
Nominally, one would do the addition for x86_32 that uses FPU for atomic load/stores. But the same file already uses the atomic built-ins for other atomic needs, so we can just rewrite 64-bit atomic accesses using built-ins. This would give us compatibility across all platforms at once.
It currently blocks testing for JDK-8319777.