[Bug middle-end/101996] New: libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1

[Bug middle-end/101996] New: libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1

[bqq3z3afgj at bcco4 dot anonbox.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996

            Bug ID: 101996
           Summary: libatomic: RISC-V 64: Infinite recursion in
                    __atomic_compare_exchange_1
           Product: gcc
           Version: 10.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bqq3z3afgj at bcco4 dot anonbox.net
  Target Milestone: ---

On Alpine Linux Edge, we noticed a stack overflow in
__atomic_compare_exchange_1 in libatomic.so. The generated RV64
assembler for the __atomic_compare_exchange_1 symbol looks as follows:

        0000000000001e40 <__atomic_compare_exchange_1@plt>:
            1e40:       00003e17                auipc   t3,0x3
            1e44:       2a0e3e03                ld      t3,672(t3) # 50e0
<__atomic_compare_exchange_1+0x2312>
            1e48:       000e0367                jalr    t1,t3
            1e4c:       00000013                nop

        0000000000002dce <__atomic_compare_exchange_1>:
            2dce:       1141                    addi    sp,sp,-16
            2dd0:       4701                    li      a4,0
            2dd2:       4695                    li      a3,5
            2dd4:       e406                    sd      ra,8(sp)
            2dd6:       86aff0ef                jal     ra,1e40
<__atomic_compare_exchange_1@plt>
            2dda:       60a2                    ld      ra,8(sp)
            2ddc:       0141                    addi    sp,sp,16
            2dde:       8082                    ret

It seems to me that __atomic_compare_exchange_1 calls itself recursively
via __atomic_compare_exchange_1@plt each time adding a new stackframe in
2dce, 2ddc (which pops the stack frame) is never reached due to the
recursive invocation in 2dd6. Thus ultimatly causing a stack overflow.

One theory on the #gcc IRC was that riscv claims to have atomic_*
builtins but ends up not generating them thus causing the infinite
recursion.

        $ gcc -v
        Using built-in specs.
        COLLECT_GCC=gcc
       
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-alpine-linux-musl/10.3.1/lto-wrapper
        Target: riscv64-alpine-linux-musl
        Configured with:
/home/buildozer/aports-dev/main/gcc/src/gcc-10.3.1_git20210625/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=riscv64-alpine-linux-musl --host=riscv64-alpine-linux-musl
--target=riscv64-alpine-linux-musl --with-pkgversion='Alpine
10.3.1_git20210625' --enable-checking=release --disable-fixed-point
--disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror
--disable-symvers --enable-__cxa_atexit --enable-default-pie
--enable-default-ssp --enable-cloog-backend
--enable-languages=c,c++,objc,go,fortran --with-arch=rv64gc --with-abi=lp64d
--enable-autolink-libatomic --disable-libquadmath --disable-libssp
--disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared
--enable-threads --enable-tls --disable-libitm --with-system-zlib
--with-linker-hash-style=gnu
        Thread model: posix
        Supported LTO compression algorithms: zlib
        gcc version 10.3.1 20210625 (Alpine 10.3.1_git20210625)

Downstream bug report:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/12817

[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Worksforme:

00000000000029ae <__atomic_compare_exchange_1@@LIBATOMIC_1.0>:
    29ae:       0ff0000f                fence
    29b2:       0005c683                lbu     a3,0(a1)
    29b6:       ff857893                andi    a7,a0,-8
    29ba:       891d                    andi    a0,a0,7
    29bc:       050e                    slli    a0,a0,0x3
    29be:       0ff00713                li      a4,255
    29c2:       0008b783                ld      a5,0(a7)
    29c6:       00a71733                sll     a4,a4,a0
    29ca:       00a696b3                sll     a3,a3,a0
    29ce:       00a61633                sll     a2,a2,a0
    29d2:       fff74e13                not     t3,a4
    29d6:       00fe7833                and     a6,t3,a5
    29da:       00f77333                and     t1,a4,a5
    29de:       00c86833                or      a6,a6,a2
    29e2:       02d31363                bne     t1,a3,2a08
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x5a>
    29e6:       1008b32f                lr.d    t1,(a7)
    29ea:       00f31663                bne     t1,a5,29f6
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x48>
    29ee:       1908beaf                sc.d    t4,a6,(a7)
    29f2:       fe0e9ae3                bnez    t4,29e6
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x38>
    29f6:       40f30833                sub     a6,t1,a5
    29fa:       879a                    mv      a5,t1
    29fc:       fc081de3                bnez    a6,29d6
<__atomic_compare_exchange_1@@LIBATOMIC_1.0+0x28>
    2a00:       0ff0000f                fence
    2a04:       4505                    li      a0,1
    2a06:       8082                    ret
    2a08:       00a7d7b3                srl     a5,a5,a0
    2a0c:       00f58023                sb      a5,0(a1)
    2a10:       0ff0000f                fence
    2a14:       4501                    li      a0,0
    2a16:       8082                    ret

[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1

[bqq3z3afgj at bcco4 dot anonbox.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996

--- Comment #2 from Alpine User <bqq3z3afgj at bcco4 dot anonbox.net> ---
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

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
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

[wilson at gcc dot gnu.org]

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.

[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996

--- Comment #5 from Jim Wilson <wilson at gcc dot gnu.org> ---
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

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996

--- Comment #6 from Jim Wilson <wilson at gcc dot gnu.org> ---
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

[bqq3z3afgj at bcco4 dot anonbox.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996

Alpine User <bqq3z3afgj at bcco4 dot anonbox.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #7 from Alpine User <bqq3z3afgj at bcco4 dot anonbox.net> ---
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.