On Fri, Jul 28, 2023 at 04:03:39PM +0200, Martin Uecker wrote: > > 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.
See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html for background. The thing is that user doesn't have much control over those padding bits, so whether _Atomic operations on long double (when it is 80 bit and stores from hw actually store 10 bytes rather than 12 or 16), or _BitInt(37) or _BitInt(195) or struct S { char a; int b; }; then depend purely on luck. If the expected value is based on atomic_load on the atomic_compare_exchange location or whatever atomic_compare_exchange gave back, if in the loop one e.g. adds something to it, then again it might get different padding bits from what is originally in memory, so it isn't true that it will always succeed at least in the second loop iteration. Jakub
