Re: Broken build on macOS (Universal / Intel): cpuid instruction not available

On Fri, May 8, 2026 at 12:34 AM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
>
> On Thu, May 7, 2026 at 9:22 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > I wrote:
> > > ... The code in HEAD doesn't have
> > > that guard, and is essentially assuming that every x86 platform
> > > wil provide HAVE__GET_CPUID or HAVE__CPUID.
> >
> > Independently of whether macOS multi-arch is something we consider
> > supportable, I think the aforesaid assumption is a bad idea.
> > Can't we make pg_cpuid() return zeroes if it doesn't know how to
> > get the info, analogously to what pg_cpuid_subleaf() does?

Yeah, that seems like a good assumption to remove.

Jakob and Tobias, how far do you get with the attached, at least for
the target x86 case? And it might help if you sent the configure
output in a file so we can see what we're dealing with. Note also that
we have two build systems, since we'll likely transition away from
autotools:

https://wiki.postgresql.org/wiki/Meson

> Having worked in that area in this cycle, I think returning zeroes (or
> adding a return value that confirms we got data)

Speaking of return values, the TSC feature as committed doesn't
actually use the return value of pg_cpuid_subleaf(), but it seems like
something we could use someday. I don't see such a use for pg_cpuid()
beyond having zero values in the 4 variables.

> could work for the
> TSC related functionality, since we just fall back to the system clock
> and disallow TSC use if we can't get CPUID data. I'll let John confirm
> if there are any other optimizations that require CPUID data.

Yes there are, but everything should still fallback gracefully without it.

--
John Naylor
Amazon Web Services