I realize the documentation doesn't concur with me, but as long as gcc and libgcc agree on the lock-freeness of the routines, I don't see the harm. (wrt. rv32ia, at least.)
On Wed, May 30, 2018 at 10:40 PM, asb at lowrisc dot org <gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005 > > Alex Bradbury <asb at lowrisc dot org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |asb at lowrisc dot org > Summary|[RISCV] Invalid lowering of |[RISCV] Invalid intermixing > |atomics for -march=rv32i / |of __atomic_* libcalls and > |-march=rv64i |inline atomic instruction > | |sequences > > --- Comment #1 from Alex Bradbury <asb at lowrisc dot org> --- > Actually I think this bug is wider in scope than I first thought. GCC will > also > intermix __atomic libcalls and inline instruction sequences with -march=rv32ia > when values less than XLEN in size are accessed. > > $ cat foo.c > char atomic(char *i) { > char j = __atomic_add_fetch(i, 1, __ATOMIC_SEQ_CST); > char k; > __atomic_load(i, &k, __ATOMIC_SEQ_CST); > return j+k; > } > > $ ./riscv32-unknown-elf-gcc -march=rv32ia foo.c -O1 -S -o - > .file "foo.c" > .option nopic > .text > .align 2 > .globl atomic > .type atomic, @function > atomic: > addi sp,sp,-16 > sw ra,12(sp) > sw s0,8(sp) > mv s0,a0 > li a2,5 > li a1,1 > call __atomic_fetch_add_1 > addi a0,a0,1 > andi a0,a0,0xff > fence iorw,iorw > lbu a5,0(s0) > fence iorw,iorw > add a0,a0,a5 > andi a0,a0,0xff > lw ra,12(sp) > lw s0,8(sp) > addi sp,sp,16 > jr ra > .size atomic, .-atomic > .ident "GCC: (GNU) 9.0.0 20180530 (experimental)"
