https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759
--- Comment #1 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
I need to withdraw the fix for this PR, it is a red herring that has
misled me.
While there is a data race here it is not within access to the atomic
data object, it comes from the *outside*. Consider this code:
unsigned short x;
_Atomic unsigned short y;
unsigned short z;
void
write_x (unsigned short v)
{
x = v;
}
void
write_y (unsigned short v)
{
y = v;
}
void
write_z (unsigned short v)
{
z = v;
}
Data objects defined here compile to:
.globl z
.section .sbss,"aw"
.type z, @object
.size z, 2
.align 1
z:
.zero 2
.globl y
.type y, @object
.size y, 2
.align 1
y:
.zero 2
.globl x
.type x, @object
.size x, 2
.align 1
x:
.zero 2
There is no data race with parallel calls to `write_y' on different CPUs,
because the previous value of `y' is ignored. There is a race condition
between the calls, but it is fine and can be resolved by the code author
if required.
There is a data race with parallel calls to, depending on final alignment,
either `write_x' and `write_y', or `write_z' and `write_y', e.g:
time CPU0 CPU1 CPU2
|
| ... ldq_u ..., x ldq_u ..., z
| ldq_l ..., y . .
| ... . .
| stq_c ..., y . .
V ... stq_u ..., x stq_u ..., z
In this execution scenario `y' *will* get clobbered by either CPU1 or CPU2
despite the atomic sequence executed by CPU0.
This data race cannot be resolved with making the access atomic to `y'
alone, `atomic_storeMODE' won't help here. Accesses to `x', `y' and `z'
all need to be made atomic to prevent this data race from happening, as
implemented with the `-msafe-bwa' feature posted separately; cf.
<https://inbox.sourceware.org/gcc-patches/alpine.deb.2.21.2411172309330.59...@angie.orcam.me.uk/>.
