Hi!
On 2025-01-13T11:04:50+0000, Jonathan Wakely <[email protected]> wrote:
> On Mon, 13 Jan 2025 at 11:03, Thomas Schwinge <[email protected]> wrote:
>> On 2025-01-12T08:38:05+0100, Torbjorn SVENSSON
>> <[email protected]> wrote:
>> > On 2025-01-12 01:05, Jonathan Wakely wrote:
>> >> On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
>> >> <[email protected] <mailto:[email protected]>>
>> >> wrote:
>> >>
>> >> Ok for trunk and releases/gcc-14?
>> >>
>> >> OK
>> >
>> > Pushed as r15-6828-g4b0ef49d02f and r14.2.0-680-gd82fc939f91.
>>
>> On a configuration where libatomic does get built, I see (with standard
>
> Does *not* get built?
No, *does* get built, and thus the PASS -> UNSUPPORTED is a regression.
Grüße
Thomas
>> build-tree testing: 'make check'):
>>
>> [-PASS:-]{+UNSUPPORTED:+}
>> 29_atomics/atomic_float/compare_exchange_padding.cc -std=gnu++20[-(test for
>> excess errors)-]
>> [-PASS: 29_atomics/atomic_float/compare_exchange_padding.cc
>> -std=gnu++20 execution test-]
>> [Etc.]
>>
>> [...]
>> spawn -ignore SIGHUP [...]/gcc/xg++ [...] libatomic_available1221570.c
>> -latomic [...] -o libatomic_available1221570.exe
>> /usr/bin/ld: cannot find -latomic: No such file or directory
>> [...]
>>
>> I presume that the new 'dg-require-effective-target libatomic_available'
>> is evaluated when the 'atomic_link_flags' via 'dg-additional-options'
>> have not yet been set?
>>
>> Would it work to call 'atomic_init' (plus 'atomic_finish', I suppose?)
>> (see 'gcc/testsuite/lib/atomic-dg.exp') in libstdc++ test suite setup,
>> and then to '29_atomics/atomic_float/compare_exchange_padding.cc' apply
>> the usual pattern:
>>
>> -// { dg-require-effective-target libatomic_available }
>> -// { dg-additional-options "[atomic_link_flags [get_multilibs]]
>> -latomic" }
>> +// { dg-additional-options -latomic { target libatomic_available } }
>
> Yes that seems OK
