Horton
Menu

Re: Centralised architecture detection

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nico Williams <nico@cryptonector.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>, Lukas Fittl <lukas@fittl.com>, John Naylor <johncnaylorls@gmail.com>, Bryan Green <dbryan.green@gmail.com>
Date: 2026-06-03T21:27:22Z
Lists: pgsql-hackers 
Nico Williams <nico@cryptonector.com> writes:
> On Wed, Jun 03, 2026 at 05:08:55PM -0400, Tom Lane wrote:
>> Concretely, I'm imagining that we'd do more or less the attached in
>> c.h, and then the rest of the work would just be to remove the
>> not-very-large number of references to the alternative CPU symbols.

> Can a pre-processor make it an error for users to define __ macros?

I don't believe so.  We have done similar things elsewhere, eg
before 25f36066d we had this in solaris.h:

/*
 * Sort this out for all operating systems some time.  The __xxx
 * symbols are defined on both GCC and Solaris CC, although GCC
 * doesn't document them.  The __xxx__ symbols are only on GCC.
 */
#if defined(__i386) && !defined(__i386__)
#define __i386__
#endif

#if defined(__amd64) && !defined(__amd64__)
#define __amd64__
#endif

#if defined(__x86_64) && !defined(__x86_64__)
#define __x86_64__
#endif

#if defined(__sparc) && !defined(__sparc__)
#define __sparc__
#endif

Of course that only proves that Sun Studio didn't complain.

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix CPU-identification macros for RISC-V.

  2. Clean up inconsistencies in CPU-identification macros.