Re: Build failure with GCC 15 (defaults to -std=gnu23) - Mailing list pgsql-bugs

On Tue, Nov 26, 2024 at 9:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If we leave it like this, alligator will need some configuration
> adjustments, and so will other BF animals when they migrate to new
> gcc, and so will individual hackers when they're trying to build
> old branches.  A possible compromise to reduce the manual pain
> level could be to adjust configure to add "-std=gnu99" or so to
> CFLAGS in the pre-v16 branches, if the compiler accepts that.

We already have tests to see if we need to add -std=c99 to go forwards
in time (from a quick look at the build farm, now used only by EOL
distros testing GCC 4).  Something tells me we might want to be less
draconian when travelling backwards, but I dunno... our stuff is
working fine with (implicit) -std=c17 all over the place, and we also
have:

# Do we need -std=c99 to compile C99 code? We don't want to add -std=c99
# unnecessarily, because we optionally rely on newer features.

I noticed that later autoconf killed AC_PROG_CC_C99 and its AC_PROG_CC
is figuring out the highest C standard available and requesting that,
though it doesn't know about C23 yet.

> (OTOH, maybe that'd cause pain for some extensions?)

So we're talking about -std=XXX suddenly appearing in pg_config
--cflags?  Of course we want to try quite hard to keep emitting
nothing for that if we can.  We already emit -std=gnu99 from old tests
that keep those GCC 4 build farm zombies at bay (did extensions ever
complain about that back in the GCC 4 days?  I'd guess not), but no
one really uses those in real life.  If we one day dare to dream about
moving our own baseline to C11/C17, we'll still emit nothing as the
compilers are already there by default.  We will start to emit a new
flag to disable C23 if required, but I think it might be unlikely to
upset anyone if it works something like this:

* For 16+ nothing, we're going to be C23 clean (after a couple more
back-patches)
* For 9.2-15 on GCC < 15 it'll stay as nothing too
* For 9.2-15 on early GCC 15 adopter distros like Fedora/Gentoo etc
we'll detect C23, and perhaps start spitting out -std=c17 (if you've
detected C23, I think you can assume that C17 is available so we don't
have to do a C17-C11-C99[-C89] search?)
* When 12-15 fall out of support and all compilers are eventually C23+
compilers, they'll eventually always be getting -std=c17 by the above
rules but no one will mind about that in the ancient branches

I think if someone writes new extension code in C23 and wants to use
it with PostgreSQL 15 that came out in 2022, they can expect a few
time travel problems, but by the time C23 really starts to take off,
15 will be retired, and it's great that we got the hardest part of
this into 16.  I don't think the problems would be too hard to deal
with if you do it.  One saving grace here is that all this stuff is
converging with C++, and we already ensure our headers are valid C++.
As for what they actually mean, we also know that C++ extensions are
happily using the tree walker stuff in the wild, which I think must be
about the same level of C calling convention abuse whether you do it
from C23 or C++, and apparently doesn't break.  Example:

https://github.com/duckdb/pg_duckdb/blob/d53247f004b154dc81275e9c4b1184c792f4865c/src/pgduckdb_hooks.cpp#L123

The C++ people aren't using --cflags of course.   I guess a
really-written-in-C23 extension using --cflags to compile its own code
would need to append -std=c23 on the end when building against 12-15
(both clang and gcc will take the last of multiple -std flags), if we
decide to start emitting -std=c17 in 12-15 because we've detected a
C23 compiler.  In 16+ they could put -std=c23 on the end, or not if
they somehow know it's the default.

We could suppress it in pg_config --cflags even though we need it to
build the backend (by the arguments above, we know the headers are
more acceptable as C23 than the backend .c files), but that seems
bound to confuse matters.  I don't know how exactly, I'm no expert in
the gnarly details of extension buildfiles, and that's just some first
thoughts.  I might try some ideas out in a few days when my local
gcc15-devel package catches up with the new defaults, and see if
everything I wrote is complete nonsense.