Re: _BitInt vs. _Atomic

[Joseph Myers <joseph@codesourcery.com>]

On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote:

> The C++ way of dealing with this is using __builtin_clear_padding,
> done on atomic stores/updates of the atomic memory (padding is cleared
> if any on the value to be stored, or on the expected and desired values).
> 
> I don't know enough about the C atomic requirements whether that is feasible
> for it as well, or whether it is possible to make the padding bits partially
> or fully set somehow non-atomically without invoking UB and then make it
> never match.

If padding bits not being reliably preserved causes problems for the 
compare-exchange loops in C in practice, then it would seem reasonable to 
use __builtin_clear_padding internally as part of implementing those cases 
of atomic compound assignment.

> And another issue is that while __atomic_load, __atomic_store,
> __atomic_exchange and __atomic_compare_exchange work on arbitrary _BitInt
> sizes, others like __atomic_fetch_add only support _BitInt or other integral
> types which have size of 1, 2, 4, 8 or 16 bytes, others emit an error
> in c-family/c-common.cc (sync_resolve_size).  So, either
> resolve_overloaded_builtin should for the case when pointer is pointer to
> _BitInt which doesn't have 1, 2, 4, 8 or 16 bytes size lower those into
> a loop using __atomic_compare_exchange (or perhaps also if there is
> padding), or <stdatomic.h> should do that.

The <stdatomic.h> interfaces definitely need to work with _BitInt.  My 
guess is that doing this with the built-in expansion would be more robust 
than putting more complicated definitions in the header that choose which 
built-in functions to use depending on properties of the type (and keeping 
the built-in functions limited to certain widths), but I don't know.

Note also that those <stdatomic.h> operations have no undefined behavior 
on signed integer overflow.

If any ABIs require sign / zero extension of _BitInt values in memory, 
care would also be needed in the case of (size of 1, 2, 4, 8 or 16 bytes, 
but also has high bits required to be sign / zero extended) to ensure that 
the operations are implemented so as to leave the high bits with the 
expected values in case of overflow, which wouldn't result from simply 
using the underlying operation for a type with the full precision of its 
memory size.

-- 
Joseph S. Myers
joseph@codesourcery.com