>>> So, is this hardware limitation something that is likely to affect other >>> packages? Is there something we could look for in how they consume >>> atomic types to tell? I would hate for us to ship something else that is >>> subject to this problem. >> >> >> There is lots of fingerpointing, but no clear technical cause. >> >> We know that the (updated) i386 ABI is buggy in the sense that it does not >> provide 8-byte alignment for 64-bit values (even if you use C11 _Atomic), >> and the Intel manual says that the CMPXCHG8B instructions provides atomicity >> for 8-byte-aligned memory locations only. But it's not clear if this is the >> cause of the observed problems. >> >> Note that while GCC produces broken code, this is actually an ABI bug, and >> we cannot change struct layout rules for long long retroactively. Maybe we >> could for _Atomic long long, but that would need a lengthy investigation, >> and I strongly believe that everyone is better off if the time is spent on >> improving 64-bit architectures. >> >> Applications should not use 64-bit atomics on i386. They are non-portable >> anyway because other 32-bit architectures (actually even the original i386) >> do not support them, so upstream needs alternatives anyway. >> > > Just to be clear, when other 32 bit architectures don't support it.. > if this code was attempted to be compiled on arm32 the compiler > complains and errors? I am wanting to make sure we don't have some > sort of silent snake in the other 32 bit architecture that i386 sort > of showed first? [If they use a different method on arm32, can they > use it on the i386? Or is there something about i386 not being really > i386 (aka i686 etc) that makes this impossible. ]
The way I read some of the comments on the bugs in reviewing the code it seems it could just as well happen on any architecture, it's just easier to trigger (I explicitly steer clear of the term reproduce) on i686. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
