Re: Does MSVC predefine __x86_64__ on 64-bit Intel?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Does MSVC predefine __x86_64__ on 64-bit Intel?
Date: 2026-06-03 19:13:07
Message-ID: 3099321.1780513987@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> On 03.06.26 18:17, Tom Lane wrote:
>> Not being a Windows person, I can't easily answer these
>> questions by experiment. But I think they need answering
>> (and then documenting).

> This can be tested on https://godbolt.org/. My testing there suggests
> that neither __x86_64__ nor __x86_64 are defined.

Ah, of course. I duplicated your results about __x86_64__ (and
also verified that __i386__ doesn't get set). Sadly, godbolt
doesn't seem to have anything for the ARM64EC environment,
so I can't check that _M_X64 operates as documented.

The direction I had in mind to go here was to remove all the
references to _M_X64 (all three of them...) and instead set
things up in some central header so that on MSVC we define
the appropriate one of __i386__, __x86_64__, __arm__,
or __aarch64__ for ourselves, allowing those symbols to be
used for arch selection independently of the compiler.
(This is analogous to what we used to do for Sun Studio,
until you removed support for that in 25f36066d.)

This might expose some hidden compiler dependencies in code
currently guarded by these symbols, but if so I think we ought to
fix that with explicit _MSC_VER guards rather than relying on
these arch symbols to be compiler-specific.

We also have three or so places relying on _M_AMD64, which
seems to be just another spelling of _M_X64.

I'm also seeing a few stray references to __i386, which
I think are redundant since the Sun-Studio-ectomy.

If there are not objections I'll prepare a patch to clean
this up.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2026-06-03 19:23:48 Re: PostgreSQL 19 Beta 1 release announcement draft
Previous Message Nathan Bossart 2026-06-03 18:59:37 Re: alert clients when prepared statements are deallocated