https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996
Jim Wilson <wilson at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilson at gcc dot gnu.org
--- Comment #4 from Jim Wilson <wilson at gcc dot gnu.org> ---
The only way I can reproduce this is if I hand modify configure output. In the
riscv64-unknown-linux-gnu/libatomic/ build dir there is a auto-config.h file
that has
#define HAVE_ATOMIC_CAS_1 0
If I modify that to
#define HAVE_ATOMIC_CAS_1 1
then I get the same result where atomic_compare_exchange_1 calls itself.
libat_compare_exchange_1:
addi sp,sp,-16
li a4,0
li a3,5
sd ra,8(sp)
call __atomic_compare_exchange_1
ld ra,8(sp)
addi sp,sp,16
jr ra
.set __atomic_compare_exchange_1,libat_compare_exchange_1
The question would then be why you get this configure result. In the
config.log file in the same dir I see
configure:13591: checking for __atomic_compare_exchange for size 1
configure:13611:
/scratch/jimw/riscv-gnu-toolchain/X-tmp/build-gcc-linux-stage2/./gcc/xgcc
-B/scratch/jimw/riscv-gnu-toolchain/X-tmp/build-gcc-linux-stage2/./gcc/
-B/scratch/jimw/riscv-gnu-toolchain/X-tmp/build-install/riscv64-unknown-linux-gnu/bin/
-B/scratch/jimw/riscv-gnu-toolchain/X-tmp/build-install/riscv64-unknown-linux-gnu/lib/
-isystem
/scratch/jimw/riscv-gnu-toolchain/X-tmp/build-install/riscv64-unknown-linux-gnu/include
-isystem
/scratch/jimw/riscv-gnu-toolchain/X-tmp/build-install/riscv64-unknown-linux-gnu/sys-include
-o conftest -O2 -mcmodel=medlow -fno-sync-libcalls conftest.c >&5
/scratch/jimw/riscv-gnu-toolchain/X-tmp/build-install/riscv64-unknown-linux-gnu/bin/ld:
/tmp/ccEYquRC.o: in function `main':
conftest.c:(.text.startup+0xa): undefined reference to
`__atomic_compare_exchange_1'
collect2: error: ld returned 1 exit status
configure:13614: $? = 1
configure:13642: result: no
You should check the auto-config.h and config.log files in your gcc build.
I don't think that the compiler version matters. I see you are using musl
which is something I haven't been testing. Maybe there is something in musl
that is confusing the libatomic build. Or maybe there is something about the
way that Alpine Linux is compiling gcc that is causing the wrong result.
It looks like either an Alpine Linux problem or a musl problem to me. I don't
have a system running Alpine Linux and don't know how to set one up offhand
which limits what I can immediately do.
