https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #9 from Jim Wilson <wilson at gcc dot gnu.org> ---
Oops, hitting tab doesn't work as expected. Trying again...
This looks like a generic GCC problem, not a RISC-V specific problem. Or
perhaps, not a gcc bug at all.
For instance, if I build an armv6t2 compiler I get
bl __atomic_fetch_add_4
...
mcr p15, 0, r0, c7, c10, 5
ldr r3, [r3]
mcr p15, 0, r0, c7, c10, 5
where the mcr is equivalent to the RISC-V fence. It looks like MIPS16 and a
number of other targets have the same problem.
GCC has no support for calling __atomic_load_4 for this testcase. GCC assumes
that loads smaller or equal to the word size are always atomic, and will not
call a library routine for them. It will emit memory barriers.
If what gcc is doing is wrong, then it is broken for all targets that don't
inline expand every atomic function call, and/or don't have atomic
instructions.
I can fix the rv32ia support by inlining expanding every atomic function call.
I can't fix the rv32i support without target independent optimizer changes.
