Does MSVC predefine __x86_64__ on 64-bit Intel?
I started wondering about $SUBJECT after noting that a very small
number of places in our code have tests like
#if defined(__x86_64__) || defined(__x86_64) || defined(_M_X64) /* gcc, msvc */
That's from src/include/port/atomics/arch-x86.h, and the last
two checks are demonstrably useless, because that whole file
only gets included if
#elif defined(__i386__) || defined(__i386) || defined(__x86_64__)
#include "port/atomics/arch-x86.h"
I did some googling and found
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-180
which says nothing about either __i386__ or __x86_64__, but
does aver that
_M_X64 Defined as the integer literal value 100 for
compilations that target x64 processors or ARM64EC.
Otherwise, undefined.
So now I'm wondering if they predefine __i386__ or __x86_64__
and just don't feel a need to document that. If not, how
the heck does our code build on MSVC? Are we missing a whole
lot of CPU-specific optimizations there?
Also, after reading up on what ARM64EC means:
it seems like Microsoft has managed to break _M_X64 pretty
thoroughly, because now that symbol doesn't necessarily mean
that you're on Intel hardware. So I'm thinking we need to
transition away from depending on it to make architecture
choices. Not that we were doing so in very many places,
but it seems outright dangerous to use now: people might
cargo-cult use of that symbol into places where it's not
already certain that we're building for Intel.
Not being a Windows person, I can't easily answer these
questions by experiment. But I think they need answering
(and then documenting).
regards, tom lane
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.
On Wed, Jun 03, 2026 at 08:33:50PM +0200, Peter Eisentraut wrote:
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.
Some related threads:
/messages/by-id/flat/afouZUH_eUkIj4i4@nathan
/messages/by-id/flat/CA+hUKGL8Hs-phHPugrWM=5dAkcT897rXyazYzLw-Szxnzgx-rA@mail.gmail.com
--
nathan
Peter Eisentraut <peter@eisentraut.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
Nathan Bossart <nathandbossart@gmail.com> writes:
Some related threads:
/messages/by-id/flat/afouZUH_eUkIj4i4@nathan
/messages/by-id/flat/CA+hUKGL8Hs-phHPugrWM=5dAkcT897rXyazYzLw-Szxnzgx-rA@mail.gmail.com
D'oh. Munro's well ahead of me here ...
regards, tom lane