Hi, On 2025-11-28 10:00:21 +0100, Daniel Gustafsson wrote: > > On 28 Nov 2025, at 09:44, Jakub Wartak <[email protected]> > > wrote: > > > > That's a typo in src/include/port/atomics/arch-x86.h, isn't it ?: > > if defined(__i568__) || defined(__i668__) || /* gcc i586+ */ > > If yes, then a patch is attached. Not that it harms something or > > somebody has such old hardware, but I've just spotted it while looking > > for something else. > > That indeed looks like a clear typo, but if noone has complained since 2017 > then maybe removing the checks is the right course of action?
Tomas also just found these typos, which made me find this thread. These typos are obviously mine. Ugh. I do think we should drop the 32bit support, rather than fixing the typos. While architecturally correct, the 586 indeed can do tear free 8 byte reads / writes, some quick experiments show that it's actually not entirely trivial to get the compiler to generate the right code, at least with gcc. A volatile 8 byte read / store with gcc only generates correct code when building with a newer -march= (it's using movq when correct, but it doesn't start using it with just -mmmx, which added the instruction). For 586 one needs to get the compiler to use fildq/fistpq, which I could only make happen when using the atomic builtins / C11 atomics. I also just can't get excited about expending any work on performance for 32bit builds. The proper and reliable way to do this would be to use C11 atomics [1] and have a configure test for whether C11 atomics support doing 64bit reads/writes without locks ([2]). Unfortunately that requires a newer MSVC version and specifying /experimental:c11atomics. Greetings, Andres Freund [1] https://postgr.es/m/CA%2BhUKGKFvu3zyvv3aaj5hHs9VtWcjFAmisOwOc7aOZNc5AF3NA%40mail.gmail.com [2] Annoyingly that seems to require figuring out whether long or long long is 64bit, to map to ATOMIC_LONG_LOCK_FREE / ATOMIC_LLONG_LOCK_FREE
