https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122172
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #0)
> In conclusion, I think the primary bug is that
> libstdc++-v3/include/ext/atomicity.h isn't overridden (or perhaps just
> __gnu_cxx::__exchange_and_add_single?) and in any case that the
> atomicity.h target-machinery appears to have rotten.
I agree that this has changed, but I think it's unrelated to this issue.
We no longer use config/cpu/cris/atomicity.h because using __atomic_fetch_add
works fine on an _Atomic_word. Reverting to using config/cpu/cris/atomicity.h
wouldn't help here, because __exchange_and_add_single would still use
make_unsigned<_Atomic_word>.
Do we actually need config/cpu/cris/atomicity.h nowadays? A quick test does
suggest the custom assembly code is smaller:
__Z18__exchange_and_add_using_atomic_builtinPVii:
.LFB0:
move.d $r10,$r9
move $ccr,$r13
di
move.d [$r9],$r10
btstq 5,$r13
bmi .Lsync.irqon.7
move.d $r10,$r13
Add.d $r11,$r13
ba .Lsync.irqoff.7
move.d $r13,[$r9]
.Lsync.irqon.7:
Add.d $r11,$r13
move.d $r13,[$r9]
ei
.Lsync.irqoff.7:
ret
nop
__Z25__exchange_and_addPVii:
.LFB1:
move.d $r10,$r13
#APP
;# 45 "atomic.cc" 1
move $ccr,$r9
di
move.d $r11,$r12
move.d [$r13],$r10
add.d $r10,$r12
move.d $r12,[$r13]
move $r9,$ccr
;# 0 "" 2
#NO_APP
ret
nop
Is that because __atomic_fetch_add works with any int, but the custom assembly
in config/cpu/cris/atomicity.h only has to support the 4-byte aligned
_Atomic_word?
> The secondary
> bug is the assumption that _Atomic_word is an undecorated integer
> type where std::make_unsigned<_Atomic_word> can be applied (and tertiary
> that it *can't* be applied, but that's a known issue).
That bug is entirely independent of which value we use for $atomicity_dir.
