Hello, I am not sure how this should be fixed. For example, clang generates for the test case a call to __atomic_exchange_1():
https://godbolt.org/z/EY49jPs78 >From my point of view it makes more sense, if the compiler generates calls to >_1, _2, ... variants. GCC does it for atomic_uint_least8_t operations: #include <stdatomic.h> #include <stdbool.h> #include <stdint.h> bool tas(atomic_flag *f) { return atomic_flag_test_and_set(f); } uint8_t exchange(atomic_uint_least8_t *v) { return atomic_exchange(v, 1); } uint8_t add(atomic_uint_least8_t *v, uint8_t i) { return atomic_fetch_add(v, i); } riscv-rtems6-gcc -O2 -S -o - test.c -march=rv64imc -mabi=lp64 -mcmodel=medany -mstrict-align .file "test.c" .option nopic .attribute arch, "rv64i2p1_m2p0_c2p0_zmmul1p0_zca1p0" .attribute unaligned_access, 0 .attribute stack_align, 16 .text .align 1 .globl tas .type tas, @function tas: li a1,5 tail __atomic_test_and_set .size tas, .-tas .align 1 .globl exchange .type exchange, @function exchange: li a2,5 li a1,1 tail __atomic_exchange_1 .size exchange, .-exchange .align 1 .globl add .type add, @function add: li a2,5 tail __atomic_fetch_add_1 .size add, .-add .ident "GCC: 15.1.1 20250517" .section .note.GNU-stack,"",@progbits Shouldn't GCC generate also a call to __atomic_test_and_set_1()? This function is available in libatomic right now. ----- Am 2. Jul 2025 um 13:48 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: > Hello, > > it seems that the variants without a _1, _2, ... are explicitly provided > (libatomic_i.h): > > /* And the generic sized versions. */ > void libat_load (size_t, void *, void *, int) MAN(load); > void libat_store (size_t, void *, void *, int) MAN(store); > void libat_exchange (size_t, void *, void *, void *, int) MAN(exchange); > bool libat_compare_exchange (size_t, void *, void *, void *, int, int) > MAN(compare_exchange); > bool libat_is_lock_free (size_t, void *) MAN(is_lock_free); > > I am not really sure why there is no alias to the _1 variant for the > > DECLARE_ALL_SIZED(1); > > operations. Does this patch make any sense? > > diff --git a/libatomic/libatomic_i.h b/libatomic/libatomic_i.h > index e59dd412e17..afc356d257d 100644 > --- a/libatomic/libatomic_i.h > +++ b/libatomic/libatomic_i.h > @@ -237,7 +237,8 @@ bool libat_is_lock_free (size_t, void *) > MAN(is_lock_free); > #endif > > #if IFUNC_ALT > -# define EXPORT_ALIAS(X) /* exported symbol in non-alternate file */ > +# define EXPORT_ALIAS_2(X, Y) /* exported symbol in non-alternate file */ > +# define EXPORT_ALIAS(X) > #elif defined(N) && IFUNC_NCOND(N) > # if IFUNC_NCOND(N) == 1 > # define GEN_SELECTOR(X) \ > @@ -278,18 +279,21 @@ bool libat_is_lock_free (size_t, void *) > MAN(is_lock_free); > # else > # error "Unsupported number of ifunc alternatives." > # endif > -# define EXPORT_ALIAS(X) \ > +# define EXPORT_ALIAS_2(X, Y) \ > GEN_SELECTOR(X) \ > - typeof(C2(libat_,X)) C2(ifunc_,X) \ > - ASMNAME(C2(__atomic_,X)) \ > + typeof(C2(libat_,X)) C2(ifunc_,Y) \ > + ASMNAME(C2(__atomic_,Y)) \ > __attribute__((ifunc(S(C2(select_,X))))) > +# define EXPORT_ALIAS(X) EXPORT_ALIAS_2(X, X) > #elif defined(HAVE_ATTRIBUTE_ALIAS) > -# define EXPORT_ALIAS(X) \ > - extern typeof(C2(libat_,X)) C2(export_,X) \ > - ASMNAME(C2(__atomic_,X)) \ > +# define EXPORT_ALIAS_2(X, Y) \ > + extern typeof(C2(libat_,X)) C2(export_,Y) \ > + ASMNAME(C2(__atomic_,Y)) \ > __attribute__((alias(S(C2(libat_,X))))) > +# define EXPORT_ALIAS(X) EXPORT_ALIAS_2(X, X) > #else > -# define EXPORT_ALIAS(X) /* original symbol is exported */ > +# define EXPORT_ALIAS_2(X, Y) /* original symbol is exported */ > +# define EXPORT_ALIAS(X) > #endif > > #endif /* LIBATOMIC_H */ > diff --git a/libatomic/tas_n.c b/libatomic/tas_n.c > index 036a3d23307..fad9d00b280 100644 > --- a/libatomic/tas_n.c > +++ b/libatomic/tas_n.c > @@ -114,4 +114,7 @@ SIZE(libat_test_and_set) (UTYPE *mptr, int smodel UNUSED) > #endif > > EXPORT_ALIAS (SIZE(test_and_set)); > +#if N == 1 > +EXPORT_ALIAS_2 (SIZE(test_and_set), test_and_set); > +#endif > #undef LAT_TAS_N > > ----- Am 2. Jul 2025 um 9:20 schrieb Sebastian Huber > sebastian.hu...@embedded-brains.de: > >> Hello, >> >> for the RISC-V target, I would like to use the -march=rv64imc ISA variant. >> However, there is an issue with the libatomic for this target in the RTEMS >> configuration. For this test code: >> >> #include <stdatomic.h> >> >> bool tas(atomic_flag *f) >> { >> return atomic_flag_test_and_set(f); >> } >> >> GCC 15 generates: >> >> riscv-rtems6-gcc -O2 -S -o - -march=rv64imc -mabi=lp64 test.c >> .file "test.c" >> .option nopic >> .attribute arch, "rv64i2p1_m2p0_c2p0_zmmul1p0_zca1p0" >> .attribute unaligned_access, 0 >> .attribute stack_align, 16 >> .text >> .align 1 >> .globl tas >> .type tas, @function >> tas: >> li a1,5 >> tail __atomic_test_and_set >> .size tas, .-tas >> .ident "GCC: 15.1.1 20250517" >> .section .note.GNU-stack,"",@progbits >> >> In the corresponding libatomic.a multilib, there are the following functions >> (omitting *_4, *_8, *_16 variants which exist for all *_1 variants): >> >> __atomic_add_fetch_1 >> __atomic_and_fetch_1 >> __atomic_compare_exchange >> __atomic_compare_exchange_1 >> __atomic_exchange >> __atomic_exchange_1 >> __atomic_feraiseexcept >> __atomic_fetch_add_1 >> __atomic_fetch_and_1 >> __atomic_fetch_nand_1 >> __atomic_fetch_or_1 >> __atomic_fetch_sub_1 >> __atomic_fetch_xor_1 >> __atomic_is_lock_free >> __atomic_load >> __atomic_load_1 >> __atomic_nand_fetch_1 >> __atomic_or_fetch_1 >> __atomic_store >> __atomic_store_1 >> __atomic_sub_fetch_1 >> __atomic_test_and_set_1 >> __atomic_xor_fetch_1 >> >> Some operations have a variant without a _1, _2, _4, _8, and _16 postfix >> (example: __atomic_store). Others do not have such a variant, examples: >> __atomic_test_and_set_1, __atomic_add_fetch_1. >> >> I am a bit clueless what is going on here. Are the missing variants a >> libatomic >> configuration error? Is it a general configuration error or specific to >> RTEMS? >> >> -- >> embedded brains GmbH & Co. KG >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> phone: +49-89-18 94 741 - 16 >> fax: +49-89-18 94 741 - 08 >> >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ > > -- > embedded brains GmbH & Co. KG > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
