Re: Centralised architecture detection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Lukas Fittl <lukas(at)fittl(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, Bryan Green <dbryan(dot)green(at)gmail(dot)com>
Subject: Re: Centralised architecture detection
Date: 2026-06-03 19:24:22
Message-ID: 3100002.1780514662@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari(at)ilmari(dot)org> writes:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
>> Instead of repeating compilers' architecture macros throughout the tree
>> and sometimes getting it wrong, let's detect them in one central place,
>> and define our own macros of the form:
>>
>> PG_ARCH_{ARM,LOONGARCH,MIPS,PPC,RISCV,S390,SPARC,X86}
>> PG_ARCH_{ARM,LOONGARCH,MIPS,PPC,RISCV,S390,SPARC,X86}_{32,64}

Nathan Bossart reminded me of this thread after I'd independently
rediscovered the same thing [1]. I agree with standardizing on
just one spelling of these CPU-type macros. But I wonder why we
should invent our own instead of standardizing on gcc's spellings
(that is, __x86_64__ etc). The amount of code churn required for
this patch would drop drastically if we did it that way. And I
suspect it would be less likely that we'd need to fixup future patch
submissions than if we have a homegrown standard.

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/3035145.1780503430%40sss.pgh.pa.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-06-03 19:25:15 Re: Does MSVC predefine __x86_64__ on 64-bit Intel?
Previous Message Jonathan S. Katz 2026-06-03 19:23:48 Re: PostgreSQL 19 Beta 1 release announcement draft