Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wUr1e-001UeZ-33 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jun 2026 19:13:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wUr1d-003246-1o for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jun 2026 19:13:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wUr1d-00323x-0s for pgsql-hackers@lists.postgresql.org; Wed, 03 Jun 2026 19:13:13 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wUr1a-000000016eC-3ktu for pgsql-hackers@lists.postgresql.org; Wed, 03 Jun 2026 19:13:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 653JD7Ji3099322; Wed, 3 Jun 2026 15:13:07 -0400 From: Tom Lane To: Peter Eisentraut cc: pgsql-hackers@lists.postgresql.org Subject: Re: Does MSVC predefine __x86_64__ on 64-bit Intel? In-reply-to: <2d70e27e-e9e0-417f-94fa-8ecc07c6e578@eisentraut.org> References: <3035145.1780503430@sss.pgh.pa.us> <2d70e27e-e9e0-417f-94fa-8ecc07c6e578@eisentraut.org> Comments: In-reply-to Peter Eisentraut message dated "Wed, 03 Jun 2026 20:33:50 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3099320.1780513987.1@sss.pgh.pa.us> Date: Wed, 03 Jun 2026 15:13:07 -0400 Message-ID: <3099321.1780513987@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut 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