Horton
Menu

Re: Build failure with GCC 15 (defaults to -std=gnu23)

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Sam James <sam@gentoo.org>, pgsql-bugs@lists.postgresql.org
Date: 2024-11-25T10:01:54Z
Lists: pgsql-bugs 
On Thu, Nov 21, 2024 at 8:23 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 20.11.24 16:32, Tom Lane wrote:
> > Yeah.  Our normal theory for this kind of thing is "people are
> > likely to build our old branches with modern toolchains", so
> > we are going to have to back-patch C23 compatibility sooner or
> > later.  In fact, we'll have to back-patch to 9.2, or else
> > decide that those branches are unbuildable on modern platforms
> > and hence out of scope for compatibility testing.
>
> I have checked that with this patch and the two above (well, one is just
> to remove a warning), you can get PG16 and up building cleanly with
> gcc-14 -std=gnu23.

Thanks.  I pushed the <stdbool.h> thing, which didn't require going
back very far.

> Before that, you get a ton of warnings and errors related to the node
> tree walker routines.  This is presumably related to commit 1c27d16e6e5.

Alligator is now getting past the bool troubles and reaching that
stuff.  I was expecting it to be green in master.  It's OK on my
slightly older "gcc version 15.0.0 20241110 (experimental) (FreeBSD
Ports Collection)" with -std=gnu23, but alligator now shows a weird
error with tsearch data types.  Something about flexible array members
(casting from non-flex to flex?, without saying where the cast is?),
but IDK, it's an internal error asking for a bug to be filed, not a
user-facing one.

This might be relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688

> Going further back, the bool patch proposed here assumes that stdbool.h
> exists unconditionally, which is C99, which is not the baseline for
> older branches.  I think for those it's probably best to leave it alone
> and just use gcc-15 -std=gnu89 or whatever.

There's only one C89 branch that knows about <stdbool.h>:
REL_11_STABLE.  That's recent enough that it's still easy to work
with, so I just changed it to use AC_CHECK_HEADER instead.  In other
words, we've removed the bogus "conforms" check.  Whether you still
need a presence check depends on the C version, and only for 11 is the
answer yes.  Obviously nobody is really going to build with an actual
C89 system so the presence check is never going to fail, but it would
be weird on principle to suddenly require a C99 thing...

Commits

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

  1. Require sizeof(bool) == 1.

  2. If a C23 compiler is detected, try asking for C17.

  3. Fix C23 compiler warning

  4. Rename C23 keyword

  5. Assume that <stdbool.h> conforms to the C standard.

  6. Revise tree-walk APIs to improve spec compliance & silence warnings.