Re: Fix typo 586/686 in atomics/arch-x86.h

Hi,

On 2025-11-28 10:00:21 +0100, Daniel Gustafsson wrote:
> > On 28 Nov 2025, at 09:44, Jakub Wartak <jakub.wartak@enterprisedb.com> 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