Am Freitag, dem 28.07.2023 um 16:03 +0200 schrieb Martin Uecker: > > > On Thu, Jul 27, 2023 at 07:06:03PM +0000, Joseph Myers wrote: > > > I think there should be tests for _Atomic _BitInt types. Hopefully > > > atomic > > > compound assignment just works via the logic for compare-and-exchange > > > loops, but does e.g. atomic_fetch_add work with _Atomic _BitInt types? > > > > So, there are 2 issues. > > > > One is something I haven't seen being handled for C at all so far, but > > handled for C++ - padding bits. > > > > Already e.g. x86 long double has some padding bits - 16 bits on ia32, > > 48 bits on x86_64, when one does > > _Atomic long double l; > > ... > > l += 2.0; > > it will sometimes work and sometimes hang forever. > > Similarly atomic_compare_exchange with structs which contain padding > > (unions with padding bits are lost case, there is nothing that can be > > reliably done for that, because we don't know at runtime what is the active > > union member if any). And _BitInt if it doesn't use all bits in > > all containing limbs has padding as well (and psABI doesn't say it is sign > > or zero extended). > > What is the problem here? In C, atomic_compare_exchange is defined in terms > of the memory content which includes padding. So it may fail spuriously > due to padding differences (but it may fail anyway for arbitrary reasons > even without padding differences), but then should work in the second > iterations.
(only the weak version can fail spuriously, but the strong one can still fail if there are differences in the padding)
