On 28 March 2018 at 03:58, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > On 03/28/2018 06:10 AM, Kevin Fenzi wrote: >> >> 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. ] -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
