c11: --as-needed -latomic on riscv but not others

c11: --as-needed -latomic on riscv but not others

[Mathieu Malaterre]

Hi all,

I am staring at the following discussion, which eventually was resolved with:

* https://github.com/riscv-collab/riscv-gcc/issues/12#issuecomment-276587351

Copied here for convenience (*).

So if I understand the discussion correctly gcc is now adding by
default `--as-needed -latomic` for riscv arch to support c11/atomics.
What I fail to understand is why something identical was not applied
to powerpc/armel and mipsel ?

Typically on mipsel (Debian gcc 11.2.0 toolchain):

% cat a.c
_Atomic(long long) ll;

int main(void)
{
        ++ll;
        return 0;
}

Result in:

% gcc a.c
/usr/bin/ld: /tmp/ccsr7u8u.o: in function `main':
a.c:(.text+0x54): undefined reference to `__atomic_fetch_add_8'
/usr/bin/ld: a.c:(.text+0x5c): undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status

So currently, gcc wants the developer to add explicitly `--as-needed
-latomic` to the linker to get c11/atomics support. Would it make
sense to patch gcc so that `--as-needed -latomic` is added also for
those arches (powerpc, armel, mipsel...).

Thanks for comments,
-M

(*)

diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
index d77ba3fcf27..1fab15fc081 100644
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -24,6 +24,12 @@ along with GCC; see the file COPYING3.  If not see

 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-riscv" XLEN_SPEC "-"
ABI_SPEC ".so.1"

+/* Because RISC-V only has word-sized atomics, it requries libatomic where
+   others do not.  So link libatomic by default, as needed.  */
+#undef LIB_SPEC
+#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
+  " " LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION \
+
 #define LINK_SPEC "\
 -melf" XLEN_SPEC "lriscv \
 %{shared} \

Re: c11: --as-needed -latomic on riscv but not others

[Jonathan Wakely]

On Fri, 17 Dec 2021, 07:49 Mathieu Malaterre, <malat@debian.org> wrote:

> Hi all,
>
> I am staring at the following discussion, which eventually was resolved
> with:
>
> *
> https://github.com/riscv-collab/riscv-gcc/issues/12#issuecomment-276587351
>
> Copied here for convenience (*).
>
> So if I understand the discussion correctly gcc is now adding by
> default `--as-needed -latomic` for riscv arch to support c11/atomics.
> What I fail to understand is why something identical was not applied
> to powerpc/armel and mipsel ?
>

Probably because it was a decision by the risc-v target maintainers, who
can decide what they want for their target, but not for other targets.



> Typically on mipsel (Debian gcc 11.2.0 toolchain):
>
> % cat a.c
> _Atomic(long long) ll;
>
> int main(void)
> {
>         ++ll;
>         return 0;
> }
>
> Result in:
>
> % gcc a.c
> /usr/bin/ld: /tmp/ccsr7u8u.o: in function `main':
> a.c:(.text+0x54): undefined reference to `__atomic_fetch_add_8'
> /usr/bin/ld: a.c:(.text+0x5c): undefined reference to
> `__atomic_fetch_add_8'
> collect2: error: ld returned 1 exit status
>
> So currently, gcc wants the developer to add explicitly `--as-needed
> -latomic` to the linker to get c11/atomics support. Would it make
> sense to patch gcc so that `--as-needed -latomic` is added also for
> those arches (powerpc, armel, mipsel...).
>
> Thanks for comments,
> -M
>
> (*)
>
> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> index d77ba3fcf27..1fab15fc081 100644
> --- a/gcc/config/riscv/linux.h
> +++ b/gcc/config/riscv/linux.h
> @@ -24,6 +24,12 @@ along with GCC; see the file COPYING3.  If not see
>
>  #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-riscv" XLEN_SPEC "-"
> ABI_SPEC ".so.1"
>
> +/* Because RISC-V only has word-sized atomics, it requries libatomic where
> +   others do not.  So link libatomic by default, as needed.  */
> +#undef LIB_SPEC
> +#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
> +  " " LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION \
> +
>  #define LINK_SPEC "\
>  -melf" XLEN_SPEC "lriscv \
>  %{shared} \
>

Re: c11: --as-needed -latomic on riscv but not others

[Jim Wilson]

On Thu, Dec 16, 2021 at 11:48 PM Mathieu Malaterre <malat@debian.org> wrote:

> So if I understand the discussion correctly gcc is now adding by
> default `--as-needed -latomic` for riscv arch to support c11/atomics.
> What I fail to understand is why something identical was not applied
> to powerpc/armel and mipsel ?
>

RISC-V is the only major target that does not support subword atomics.
Some ports have hardware support for subword atomics.  Some ports like PPC
lack hardware support for subword atomics but have gcc patterns to
implement them using full word atomic instructions.   RISC-V has neither.
So anything using subword atomics on RISC-V will fail to link unless
-latomic is used, but will link fine on all other major targets.
Unfortunately, there are many package maintainers that refuse to add
-latomic to their packages because x86/arm doesn't need it.  So we modified
the compiler to add the necessary -latomic option.  However, in the FSF
tree, we only add -latomic when -pthread is used, because pthread
definitely needs subword atomic support. Though convincing people to use
the -pthread option is another issue, some package maintainers refuse to
use it even though the gcc docs say it is required.  It looks like you have
a modified source tree that is adding the -latomic always which is one way
to fix that problem.

Adding gcc patterns to expand subword atomics into sequences of code using
full word atomic instructions would be a better fix, but it is a
complicated one.  There are issues with the libstdc++ ABI changing, and
issues of how exactly we test the patch, and issues with writing it and
proving it is correct as the RISC-V memory consistency spec is
complicated.  This has been a known problem for over 4 years, and no one
has volunteered to fix it yet.

Jim

Re: c11: --as-needed -latomic on riscv but not others

[Segher Boessenkool]

On Fri, Dec 17, 2021 at 12:00:47PM -0800, Jim Wilson via Gcc-help wrote:
> RISC-V is the only major target that does not support subword atomics.
> Some ports have hardware support for subword atomics.  Some ports like PPC
> lack hardware support for subword atomics but have gcc patterns to
> implement them using full word atomic instructions.

That was true until ISA 2.06 (POWER7, eleven years ago).

> Unfortunately, there are many package maintainers that refuse to add
> -latomic to their packages because x86/arm doesn't need it.  So we modified
> the compiler to add the necessary -latomic option.  However, in the FSF
> tree, we only add -latomic when -pthread is used, because pthread
> definitely needs subword atomic support.

The libatomic implementation requires pthread, I think?

> Though convincing people to use
> the -pthread option is another issue, some package maintainers refuse to
> use it even though the gcc docs say it is required.  It looks like you have
> a modified source tree that is adding the -latomic always which is one way
> to fix that problem.
> 
> Adding gcc patterns to expand subword atomics into sequences of code using
> full word atomic instructions would be a better fix, but it is a
> complicated one.

This might well generate worse code on average.  That is very target-
dependent of course.

> There are issues with the libstdc++ ABI changing, and
> issues of how exactly we test the patch, and issues with writing it and
> proving it is correct as the RISC-V memory consistency spec is
> complicated.  This has been a known problem for over 4 years, and no one
> has volunteered to fix it yet.

Good luck with it!  It is pretty hard work, and thankless.  For one
thing it isn't very visible.  For another a much better performance gain
will result from implementing it in hardware, and that will catch up, if
it takes another >4y to implement in software ;-)


Segher