https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC| |hp at gcc dot gnu.org
Last reconfirmed| |2023-09-22
--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Confirmed at r14-4210-g94982a6b9cf4 for arm-unknown-eabi cross from x86-linux.
I was about to enter a mostly-identical report. Exactly the same code is still
emitted (as expected with the bug present). It's not just ARMv4T, it's any ARM
architecture variant below ARMv7.
I expect swp *or at least a call to a library function to be emitted, as
happens for all other builtin atomics*. I think this much is hard to dispute.
The cause I guess, is just a bad fall-through in the arm/sync.md.
For reference, compare to the code emitted at -O2 for:
unsigned char f1 (unsigned char *x)
{
unsigned char c = *x;
*x = 1;
return c;
}
(for which the same code is emitted) and also:
unsigned char f2 (volatile unsigned char *x)
{
return __sync_lock_test_and_set (x, 1);
}
(note the call to the __sync_lock_test_and_set_1 library function)
A related issue is that those gcc doesn't provide those library functions - but
that's a whole different bug.
Though, I agree it seems that SWP should be used in preference to library
calls. Not being ARM-literate, I did some digging which indicates that SWP is
present on "V2S" and later, i.e. including armv4t, which happens to be the
default for arm-eabi, see config.gcc entry for arm-eabi, observe
'target_cpu_cname="arm7tdmi"' (and if necessary consult
gcc/config/arm/arm-cpus.in). I don't know what runtime environment caveats
there are for "swp" to work, or why rth's patch was never committed (referring
to the thread pointed to in #c2).
