[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 Alpine User changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #7 from Alpine User --- Sorry for not updating this. Yes, this is indeed a bug caused by the fact that Alpine's RISC-V GCC links against libatomic by default. See https://gitlab.alpinelinux.org/alpine/aports/-/issues/12948 for the downstream discussion. What seems to help is running the libatomic configure script as `gcc_no_link=yes ./configure`. I think this bug report can be closed in the meantime as this is not an upstream GCC bug.
[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 --- Comment #6 from Jim Wilson --- Looking at Alpine Linux discussions, I see that it has a --enable-autolink-libatomic configure option which links in libatomic by default. This could break the libatomic autoconf tests that check to see if libatomic functions exist, by linking in libatomic when we aren't expecting it. The libatomic autoconf tests are really checking to see if the calls get inline expanded. They don't want the calls to be satisified by a library. They want the calls to be undefined functions if they aren't inline expanded. These autoconf tests might need to be rewritten if more distros start linking in libatomic by default.
[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 --- Comment #5 from Jim Wilson --- A riscv-gnu-toolchain build with musl looks OK, so it looks like an Alpine Linux problem.
[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #4 from Jim Wilson --- 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: addisp,sp,-16 li a4,0 li a3,5 sd ra,8(sp) call__atomic_compare_exchange_1 ld ra,8(sp) addisp,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-libcallsconftest.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.
[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 --- Comment #3 from Andreas Schwab --- Using built-in specs. COLLECT_GCC=gcc-10 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/riscv64-suse-linux/10/lto-wrapper Target: riscv64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/10 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --program-suffix=-10 --without-system-libunwind --disable-multilib --enable-link-mutex --build=riscv64-suse-linux --host=riscv64-suse-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.3.1 20210707 [revision 048117e16c77f82598fca9af585500572d46ad73] (SUSE Linux)
[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 --- Comment #2 from Alpine User --- Can you post your `gcc -v` output? Maybe we are using different GCC version and this has been fixed already? I grepped through the commit 10.X..11.X commit log manually but wasn't able to find anything this way.
[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 --- Comment #1 from Andreas Schwab --- Worksforme: 29ae <__atomic_compare_exchange_1@@LIBATOMIC_1.0>: 29ae: 0ffffence 29b2: 0005c683lbu a3,0(a1) 29b6: ff857893andia7,a0,-8 29ba: 891dandia0,a0,7 29bc: 050esllia0,a0,0x3 29be: 0ff00713li a4,255 29c2: 0008b783ld a5,0(a7) 29c6: 00a71733sll a4,a4,a0 29ca: 00a696b3sll a3,a3,a0 29ce: 00a61633sll a2,a2,a0 29d2: fff74e13not t3,a4 29d6: 00fe7833and a6,t3,a5 29da: 00f77333and t1,a4,a5 29de: 00c86833or a6,a6,a2 29e2: 02d31363bne t1,a3,2a08 <__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x5a> 29e6: 1008b32flr.dt1,(a7) 29ea: 00f31663bne t1,a5,29f6 <__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x48> 29ee: 1908beafsc.dt4,a6,(a7) 29f2: fe0e9ae3bnezt4,29e6 <__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x38> 29f6: 40f30833sub a6,t1,a5 29fa: 879amv a5,t1 29fc: fc081de3bneza6,29d6 <__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x28> 2a00: 0ffffence 2a04: 4505li a0,1 2a06: 8082ret 2a08: 00a7d7b3srl a5,a5,a0 2a0c: 00f58023sb a5,0(a1) 2a10: 0ffffence 2a14: 4501li a0,0 2a16: 8082ret
