Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tFfMf-00EoJU-TV for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Nov 2024 20:07:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tFfMe-00088B-5e for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Nov 2024 20:07:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tFfMd-000883-T9 for pgsql-bugs@lists.postgresql.org; Mon, 25 Nov 2024 20:07:19 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tFfMb-003kBb-8Y for pgsql-bugs@lists.postgresql.org; Mon, 25 Nov 2024 20:07:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 4APK73aL1447161; Mon, 25 Nov 2024 15:07:03 -0500 From: Tom Lane To: Thomas Munro cc: Peter Eisentraut , Sam James , pgsql-bugs@lists.postgresql.org Subject: Re: Build failure with GCC 15 (defaults to -std=gnu23) In-reply-to: References: <87o72eo9iu.fsf@gentoo.org> <3073930.1731867112@sss.pgh.pa.us> <3160019.1731875201@sss.pgh.pa.us> <3169079.1731880169@sss.pgh.pa.us> <3175762.1731883847@sss.pgh.pa.us> <152145.1732116729@sss.pgh.pa.us> <485f5982-18c5-4210-9c7d-7c05453f7033@eisentraut.org> Comments: In-reply-to Thomas Munro message dated "Tue, 26 Nov 2024 08:51:21 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1447159.1732565223.1@sss.pgh.pa.us> Date: Mon, 25 Nov 2024 15:07:03 -0500 Message-ID: <1447160.1732565223@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > Oh. Yeah. 1c27d16e6e5 was not back-patchable. And what f9a56e72 did > in 15 and older doesn't seem to have any equivalent in C23, at least > without going way overboard. -Wdeprecated-non-prototype was > recognising a category of function type that no longer exists, so the > code now falls into the more general case of > -Wincompatible-pointer-types in C23, which you certainly wouldn't want > to suppress. So perhaps we actually can't make any branch older than > PostgreSQL 16 into a valid C23 program, and if that's true, I needn't > have back-patched the change any further back than 16. > Perhaps we should reconsider that, then. And if it can't be all the > back-branches, we could even decide to focus just on master. Where do > we want our C23 support to begin? Unless somebody has a better idea than 1c27d16e6e5, it would seem reasonable to say that we'll support C23 in v16 and later, but to build an older branch you have to back off to an older C version. I don't feel a need to revert those changes. If nothing else, that saved a bit of configure runtime. 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. (OTOH, maybe that'd cause pain for some extensions?) regards, tom lane