Peter Eisentraut <[email protected]> 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
