Re: [PATCH] __atomic_test_and_set: Fall back to library, not non-atomic code

[Jeff Law <jeffreyalaw@gmail.com>]

On 9/26/23 08:34, Hans-Peter Nilsson wrote:
> Tested cris-elf, native x86_64-pc-linux-gnu and arm-eabi.
> 
> For arm-eabi, notably lacking any atomic support for the
> default multilib, with --target_board=arm-sim it regressed
> 29_atomics/atomic_flag/cons/value_init.cc with the expected
> linker failure due to lack of __atomic_test_and_set - which
> is a good thing.  With this one, there are 44 unexpected
> FAILs for libstdc+++ at r14-4210-g94982a6b9cf4.  This number
> was 206 as late as r14-3470-g721f7e2c4e5e, but mitigated by
> r14-3980-g62b29347c38394, deliberately.  To fix the
> regression, I'll do the same and follow up with adding
> dg-require-thread-fence on
> 29_atomics/atomic_flag/cons/value_init.cc (and if approved,
> commit it before this one).
> 
> Incidentally, the fortran test-results for arm-eabi are
> riddled with missing-__sync_synchronize linker errors
> causing some 18134 unexpected failures, where cris-elf has
> 121.
> 
> Ok to commit?
> 
> -- >8 --
> Make __atomic_test_and_set consistent with other __atomic_ and __sync_
> builtins: call a matching library function instead of emitting
> non-atomic code when the target has no direct insn support.
> 
> There's special-case code handling targetm.atomic_test_and_set_trueval
> != 1 trying a modified maybe_emit_sync_lock_test_and_set.  Previously,
> if that worked but its matching emit_store_flag_force returned NULL,
> we'd segfault later on.  Now that the caller handles NULL, gcc_assert
> here instead.
> 
> While the referenced PR:s are ARM-specific, the issue is general.
> 
> 	PR target/107567
> 	PR target/109166
> 	* builtins.cc (expand_builtin) <case BUILT_IN_ATOMIC_TEST_AND_SET>:
> 	Handle failure from expand_builtin_atomic_test_and_set.
> 	* optabs.cc (expand_atomic_test_and_set): When all attempts fail to
> 	generate atomic code through target support, return NULL
> 	instead of emitting non-atomic code.  Also, for code handling
> 	targetm.atomic_test_and_set_trueval != 1, gcc_assert result
> 	from calling emit_store_flag_force instead of returning NULL.
OK
jeff