pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBuild failure with GCC 15 (defaults to -std=gnu23)
42+ messages / 7 participants
[nested] [flat]
Commits from this thread:
2024-11-27 97525bc5c8 Require sizeof(bool) == 1.
2024-11-27 f00c401c65 1fd57e5bbf 59ea17c43c 3f302f0ed0 170e416034 70cf253d18 5b40ce749c b1b8b8e6f1 102be6634e 0c7171b32e f4e8f137bf If a C23 compiler is detected, try asking for C17.
2024-11-26 f3834c12af f7a929a007 Fix C23 compiler warning
2024-11-26 ad89c8bda1 ae145d1de6 Rename C23 keyword
2024-11-25 0305dd3ade 15a89e2cc5 13242b64e1 e0874080c4 94817d9d94 0f6d902308 0813a5e691 bc5a4dfcf7 Assume that <stdbool.h> conforms to the C standard.
* Build failure with GCC 15 (defaults to -std=gnu23)
@ 2024-11-17 02:54 Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Sam James @ 2024-11-17 02:54 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
Hi,
postgres-17.1 fails to build with upcoming GCC 15 which defaults to
-std=gnu23 as follows:
```
In file included from ../../src/include/postgres_fe.h:25,
from checksum_helper.c:17:
../../src/include/c.h:456:23: error: two or more data types in declaration specifiers
456 | typedef unsigned char bool;
| ^~~~
../../src/include/c.h:456:1: warning: useless type name in empty declaration
456 | typedef unsigned char bool;
| ^~~~~~~
```
src/include/c.h does attempt to check for whether bool is already defined but
the check doesn't work.
There may be more issues afterwards but I haven't tried papering over
the above issue. It should be possible to reproduce w/
CFLAGS="... -std=gnu23" or CFLAGS="... -std=c23" on older GCC or Clang.
thanks,
sam
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
@ 2024-11-17 18:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-17 18:11 UTC (permalink / raw)
To: Sam James <sam@gentoo.org>; +Cc: pgsql-bugs@lists.postgresql.org
Sam James <sam@gentoo.org> writes:
> postgres-17.1 fails to build with upcoming GCC 15 which defaults to
> -std=gnu23 as follows:
I do not think we claim to support C23 yet.
Having said that, I can reproduce this on gcc 14 using -std=gnu23.
It appears that configure is deciding that <stdbool.h> is not
conformant to C99 because it doesn't declare "bool" as a macro.
Did C23 really remove that !?
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-17 19:30 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-17 19:30 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Mon, Nov 18, 2024 at 7:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sam James <sam@gentoo.org> writes:
> > postgres-17.1 fails to build with upcoming GCC 15 which defaults to
> > -std=gnu23 as follows:
>
> I do not think we claim to support C23 yet.
>
> Having said that, I can reproduce this on gcc 14 using -std=gnu23.
> It appears that configure is deciding that <stdbool.h> is not
> conformant to C99 because it doesn't declare "bool" as a macro.
> Did C23 really remove that !?
Yes, seems to be a general pattern: features introduced as keyword
_Xxx with a library macro xxx -> _Xxx (usually where xxx is already a
keyword in C++ but the C committee was afraid to unleash a new keyword
directly on the world, I guess?), and now xxx is finally graduating to
real keyword status. Other examples: static_assert, thread_local,
alignas.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-17 20:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-17 20:26 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Nov 18, 2024 at 7:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Having said that, I can reproduce this on gcc 14 using -std=gnu23.
>> It appears that configure is deciding that <stdbool.h> is not
>> conformant to C99 because it doesn't declare "bool" as a macro.
>> Did C23 really remove that !?
> Yes, seems to be a general pattern: features introduced as keyword
> _Xxx with a library macro xxx -> _Xxx (usually where xxx is already a
> keyword in C++ but the C committee was afraid to unleash a new keyword
> directly on the world, I guess?), and now xxx is finally graduating to
> real keyword status. Other examples: static_assert, thread_local,
> alignas.
Fun. Well, now that we insist on C99 support in all branches,
I wonder whether we can just remove all the non-stdbool support.
The one thing that looks tricky is that we insist on sizeof(bool)
being 1, but are there any remaining supported platforms where
it isn't? The buildfarm doesn't have any examples.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-17 21:18 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-17 21:18 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Mon, Nov 18, 2024 at 9:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fun. Well, now that we insist on C99 support in all branches,
> I wonder whether we can just remove all the non-stdbool support.
> The one thing that looks tricky is that we insist on sizeof(bool)
> being 1, but are there any remaining supported platforms where
> it isn't? The buildfarm doesn't have any examples.
So far I have found only Apple/Darwin PPC (RIP), where this was
occasionally an issue. Some projects would apparently compile with
-mone-byte-bool to unbreak local assumptions, but risk breaking ABI
with other libraries (as we do?). GCC filed that switch under Darwin
options rather than somewhere more general... can we call that a clue
that it was highly unusual?
https://gcc.gnu.org/onlinedocs/gcc/Darwin-Options.html
There may be a systematic way to survey ABIs from the LLVM or GCC
source trees... hmm, I am no expert so take this with a grain of salt
but I found where the LLVM project defines BoolWidth and BoolAlign,
starting from the commit where they removed Darwin PPC support
(2fe49ea0), and it looks like it was the only target ABI that overrode
the default of 8 there (it had 32, meaning bits).
BTW animal "alligator" has just shown the failure. Ah, yes, due to
this GCC switch being flipped a couple of days ago:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=55e3bd376b2214e200fa76d12b67ff259b06c212
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-17 21:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-17 21:49 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Nov 18, 2024 at 9:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Fun. Well, now that we insist on C99 support in all branches,
>> I wonder whether we can just remove all the non-stdbool support.
>> The one thing that looks tricky is that we insist on sizeof(bool)
>> being 1, but are there any remaining supported platforms where
>> it isn't? The buildfarm doesn't have any examples.
> So far I have found only Apple/Darwin PPC (RIP), where this was
> occasionally an issue.
Yeah. Well, what say we leave the "typedef unsigned char bool"
pathway in place, but set things up to use that only if sizeof
the stdbool type isn't 1 --- and then it's up to any hypothetical
users of that pathway to choose a compiler and compiler options
that won't choke on it.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-17 22:45 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-17 22:45 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Mon, Nov 18, 2024 at 10:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah. Well, what say we leave the "typedef unsigned char bool"
> pathway in place, but set things up to use that only if sizeof
> the stdbool type isn't 1 --- and then it's up to any hypothetical
> users of that pathway to choose a compiler and compiler options
> that won't choke on it.
It sounds like we should stop using the old and broken
AC_CHECK_HEADER_STDBOOL macro. I think it was doing two jobs in old
times: there were some systems that shipped a defective/pre-standard
stdbool.h, and some systems without it. I think both classes of
system are gone from the universe. Later autoconf versions check for
C99 "or later", but we're stuck with the old one and I doubt we are
going to upgrade it. Found in their NEWS:
*** AC_HEADER_STDBOOL, AC_CHECK_HEADER_STDBOOL are obsolescent and less picky.
These macros are now obsolescent, as programs can simply include
stdbool.h unconditionally. If you use these macros, they now accept
a stdbool.h that exists but does nothing, so long as ‘bool’, ‘true’,
and ‘false’ work anyway. This is for compatibility with C 2023 and
with C++.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-17 22:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-17 22:50 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> It sounds like we should stop using the old and broken
> AC_CHECK_HEADER_STDBOOL macro.
Yeah, that's what I was imagining: assume that <stdbool.h> exists
and works, and check only to see if sizeof(bool) is acceptable.
> ... Later autoconf versions check for
> C99 "or later", but we're stuck with the old one and I doubt we are
> going to upgrade it.
I'm not sure --- there was some discussion a week or two ago about
upgrading autoconf after all. But whether we do or not, it's hard
to see what AC_HEADER_STDBOOL is buying us.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-18 01:30 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-18 01:59 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
0 siblings, 2 replies; 42+ messages in thread
From: Thomas Munro @ 2024-11-18 01:30 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Mon, Nov 18, 2024 at 11:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > It sounds like we should stop using the old and broken
> > AC_CHECK_HEADER_STDBOOL macro.
>
> Yeah, that's what I was imagining: assume that <stdbool.h> exists
> and works, and check only to see if sizeof(bool) is acceptable.
I think this is the minimal change, which I'd push back to 13 post-freeze.
I found a few lines we could just delete in master. I wonder if we
should also just require sizeof(bool) == 1 more explicitly going
forward with an error, since we don't have coverage or any expectation
of ever getting any for the alternative code AFAICS, even if it is
small.
Attachments: download all (2 files, .tar.gz)
0001-Assume-that-stdbool.h-exists.patch (text/x-patch, 12.3K) download
From fb38dffa1b0e166a3045b751794f939bc1f01f0f Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Mon, 18 Nov 2024 12:09:09 +1300
Subject: [PATCH 1/2] Assume that <stdbool.h> exists.
Previously we checked "for <stdbool.h> that conforms to C99" using
autoconf's AC_CHECK_HEADER_STDBOOL macro. Since we require C99, it
must always exist these days, but the macro as defined doesn't cope with
C23's empty header. Later autoconf versions fixed that, but let's just
remove the anachronistic test.
HAVE_STDBOOL_H and HAVE__BOOL will no longer be defined, but they
weren't directly tested in core, or likely extensions. PG_USE_STDBOOL
is still defined when sizeof(bool) is 1: in practice always. Otherwise,
we define our own bool type and values, also certain to fail on C23 as
coded, but we don't know of any system like that in modern times.
Further cleanup work is possible, but that'd be master-only.
This came to our attention when GCC 15 recently flipped the C23 switch
by default.
Back-patch to all supported releases.
Reported-by: Sam James <sam@gentoo.org>
Reviewed-by:
Discussion: https://www.postgresql.org/message-id/flat/87o72eo9iu.fsf%40gentoo.org
---
configure | 182 +++++++++----------------------------
configure.ac | 13 +--
meson.build | 9 +-
src/include/c.h | 2 +-
src/include/pg_config.h.in | 6 --
5 files changed, 51 insertions(+), 161 deletions(-)
diff --git a/configure b/configure
index f58eae1baa8..001f0e5d46a 100755
--- a/configure
+++ b/configure
@@ -2094,116 +2094,116 @@ $as_echo "$ac_res" >&6; }
} # ac_fn_c_check_func
-# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
-# -------------------------------------------
-# Tests whether TYPE exists after having included INCLUDES, setting cache
-# variable VAR accordingly.
-ac_fn_c_check_type ()
+# ac_fn_c_check_member LINENO AGGR MEMBER VAR INCLUDES
+# ----------------------------------------------------
+# Tries to find if the field MEMBER exists in type AGGR, after including
+# INCLUDES, setting cache variable VAR accordingly.
+ac_fn_c_check_member ()
{
as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
-$as_echo_n "checking for $2... " >&6; }
-if eval \${$3+:} false; then :
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
+$as_echo_n "checking for $2.$3... " >&6; }
+if eval \${$4+:} false; then :
$as_echo_n "(cached) " >&6
else
- eval "$3=no"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-$4
+$5
int
main ()
{
-if (sizeof ($2))
- return 0;
+static $2 ac_aggr;
+if (ac_aggr.$3)
+return 0;
;
return 0;
}
_ACEOF
if ac_fn_c_try_compile "$LINENO"; then :
+ eval "$4=yes"
+else
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-$4
+$5
int
main ()
{
-if (sizeof (($2)))
- return 0;
+static $2 ac_aggr;
+if (sizeof ac_aggr.$3)
+return 0;
;
return 0;
}
_ACEOF
if ac_fn_c_try_compile "$LINENO"; then :
-
+ eval "$4=yes"
else
- eval "$3=yes"
+ eval "$4=no"
fi
rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
fi
rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
fi
-eval ac_res=\$$3
+eval ac_res=\$$4
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
$as_echo "$ac_res" >&6; }
eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
-} # ac_fn_c_check_type
+} # ac_fn_c_check_member
-# ac_fn_c_check_member LINENO AGGR MEMBER VAR INCLUDES
-# ----------------------------------------------------
-# Tries to find if the field MEMBER exists in type AGGR, after including
-# INCLUDES, setting cache variable VAR accordingly.
-ac_fn_c_check_member ()
+# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
+# -------------------------------------------
+# Tests whether TYPE exists after having included INCLUDES, setting cache
+# variable VAR accordingly.
+ac_fn_c_check_type ()
{
as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2.$3" >&5
-$as_echo_n "checking for $2.$3... " >&6; }
-if eval \${$4+:} false; then :
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval \${$3+:} false; then :
$as_echo_n "(cached) " >&6
else
+ eval "$3=no"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-$5
+$4
int
main ()
{
-static $2 ac_aggr;
-if (ac_aggr.$3)
-return 0;
+if (sizeof ($2))
+ return 0;
;
return 0;
}
_ACEOF
if ac_fn_c_try_compile "$LINENO"; then :
- eval "$4=yes"
-else
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-$5
+$4
int
main ()
{
-static $2 ac_aggr;
-if (sizeof ac_aggr.$3)
-return 0;
+if (sizeof (($2)))
+ return 0;
;
return 0;
}
_ACEOF
if ac_fn_c_try_compile "$LINENO"; then :
- eval "$4=yes"
+
else
- eval "$4=no"
+ eval "$3=yes"
fi
rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
fi
rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
fi
-eval ac_res=\$$4
+eval ac_res=\$$3
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
$as_echo "$ac_res" >&6; }
eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
-} # ac_fn_c_check_member
+} # ac_fn_c_check_type
# ac_fn_c_compute_int LINENO EXPR VAR INCLUDES
# --------------------------------------------
@@ -13122,100 +13122,6 @@ fi
## Header files
##
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for stdbool.h that conforms to C99" >&5
-$as_echo_n "checking for stdbool.h that conforms to C99... " >&6; }
-if ${ac_cv_header_stdbool_h+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-
- #include <stdbool.h>
- #ifndef bool
- "error: bool is not defined"
- #endif
- #ifndef false
- "error: false is not defined"
- #endif
- #if false
- "error: false is not 0"
- #endif
- #ifndef true
- "error: true is not defined"
- #endif
- #if true != 1
- "error: true is not 1"
- #endif
- #ifndef __bool_true_false_are_defined
- "error: __bool_true_false_are_defined is not defined"
- #endif
-
- struct s { _Bool s: 1; _Bool t; } s;
-
- char a[true == 1 ? 1 : -1];
- char b[false == 0 ? 1 : -1];
- char c[__bool_true_false_are_defined == 1 ? 1 : -1];
- char d[(bool) 0.5 == true ? 1 : -1];
- /* See body of main program for 'e'. */
- char f[(_Bool) 0.0 == false ? 1 : -1];
- char g[true];
- char h[sizeof (_Bool)];
- char i[sizeof s.t];
- enum { j = false, k = true, l = false * true, m = true * 256 };
- /* The following fails for
- HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]. */
- _Bool n[m];
- char o[sizeof n == m * sizeof n[0] ? 1 : -1];
- char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
- /* Catch a bug in an HP-UX C compiler. See
- http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
- http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
- */
- _Bool q = true;
- _Bool *pq = &q;
-
-int
-main ()
-{
-
- bool e = &s;
- *pq |= q;
- *pq |= ! q;
- /* Refer to every declared value, to avoid compiler optimizations. */
- return (!a + !b + !c + !d + !e + !f + !g + !h + !i + !!j + !k + !!l
- + !m + !n + !o + !p + !q + !pq);
-
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
- ac_cv_header_stdbool_h=yes
-else
- ac_cv_header_stdbool_h=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdbool_h" >&5
-$as_echo "$ac_cv_header_stdbool_h" >&6; }
- ac_fn_c_check_type "$LINENO" "_Bool" "ac_cv_type__Bool" "$ac_includes_default"
-if test "x$ac_cv_type__Bool" = xyes; then :
-
-cat >>confdefs.h <<_ACEOF
-#define HAVE__BOOL 1
-_ACEOF
-
-
-fi
-
-
-if test $ac_cv_header_stdbool_h = yes; then
-
-$as_echo "#define HAVE_STDBOOL_H 1" >>confdefs.h
-
-fi
-
-
for ac_header in atomic.h copyfile.h execinfo.h getopt.h ifaddrs.h mbarrier.h sys/epoll.h sys/event.h sys/personality.h sys/prctl.h sys/procctl.h sys/signalfd.h sys/ucred.h termios.h ucred.h xlocale.h
do :
as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
@@ -14956,9 +14862,7 @@ $as_echo_n "checking size of bool... " >&6; }
if ${ac_cv_sizeof_bool+:} false; then :
$as_echo_n "(cached) " >&6
else
- if ac_fn_c_compute_int "$LINENO" "(long int) (sizeof (bool))" "ac_cv_sizeof_bool" "#ifdef HAVE_STDBOOL_H
-#include <stdbool.h>
-#endif
+ if ac_fn_c_compute_int "$LINENO" "(long int) (sizeof (bool))" "ac_cv_sizeof_bool" "#include <stdbool.h>
"; then :
else
@@ -14984,7 +14888,7 @@ _ACEOF
-if test "$ac_cv_header_stdbool_h" = yes -a "$ac_cv_sizeof_bool" = 1; then
+if test "$ac_cv_sizeof_bool" = 1; then
$as_echo "#define PG_USE_STDBOOL 1" >>confdefs.h
diff --git a/configure.ac b/configure.ac
index 82c5009e3e8..f55579e5b55 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1425,8 +1425,6 @@ AC_SUBST(UUID_LIBS)
## Header files
##
-AC_HEADER_STDBOOL
-
AC_CHECK_HEADERS(m4_normalize([
atomic.h
copyfile.h
@@ -1686,14 +1684,11 @@ if test "$ac_cv_sizeof_off_t" -lt 8; then
fi
fi
-AC_CHECK_SIZEOF([bool], [],
-[#ifdef HAVE_STDBOOL_H
-#include <stdbool.h>
-#endif])
+AC_CHECK_SIZEOF([bool], [], [#include <stdbool.h>])
-dnl We use <stdbool.h> if we have it and it declares type bool as having
-dnl size 1. Otherwise, c.h will fall back to declaring bool as unsigned char.
-if test "$ac_cv_header_stdbool_h" = yes -a "$ac_cv_sizeof_bool" = 1; then
+dnl We use <stdbool.h> if bool has size 1 after including it. Otherwise, c.h
+dnl will fall back to declaring bool as unsigned char.
+if test "$ac_cv_sizeof_bool" = 1; then
AC_DEFINE([PG_USE_STDBOOL], 1,
[Define to 1 to use <stdbool.h> to define type bool.])
fi
diff --git a/meson.build b/meson.build
index 5b0510cef78..4aef6dde69b 100644
--- a/meson.build
+++ b/meson.build
@@ -1755,12 +1755,9 @@ if cc.compiles('''
endif
-# We use <stdbool.h> if we have it and it declares type bool as having
-# size 1. Otherwise, c.h will fall back to declaring bool as unsigned char.
-if cc.has_type('_Bool', args: test_c_args) \
- and cc.has_type('bool', prefix: '#include <stdbool.h>', args: test_c_args) \
- and cc.sizeof('bool', prefix: '#include <stdbool.h>', args: test_c_args) == 1
- cdata.set('HAVE__BOOL', 1)
+# We use <stdbool.h> bool has size 1 after including it. Otherwise, c.h will
+# fall back to declaring bool as unsigned char.
+if cc.sizeof('bool', prefix: '#include <stdbool.h>', args: test_c_args) == 1
cdata.set('PG_USE_STDBOOL', 1)
endif
diff --git a/src/include/c.h b/src/include/c.h
index 0a548d69d7f..b7352ed270c 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ -450,7 +450,7 @@ typedef void (*pg_funcptr_t) (void);
* bool
* Boolean value, either true or false.
*
- * We use stdbool.h if available and its bool has size 1. That's useful for
+ * We use stdbool.h if bool has size 1 after including it. That's useful for
* better compiler and debugger output and for compatibility with third-party
* libraries. But PostgreSQL currently cannot deal with bool of other sizes;
* there are static assertions around the code to prevent that.
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index cdd9a6e9355..5220e1222f5 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -361,9 +361,6 @@
/* Define to 1 if you have the `SSL_CTX_set_num_tickets' function. */
#undef HAVE_SSL_CTX_SET_NUM_TICKETS
-/* Define to 1 if stdbool.h conforms to C99. */
-#undef HAVE_STDBOOL_H
-
/* Define to 1 if you have the <stdint.h> header file. */
#undef HAVE_STDINT_H
@@ -493,9 +490,6 @@
/* Define to 1 if you have XSAVE intrinsics. */
#undef HAVE_XSAVE_INTRINSICS
-/* Define to 1 if the system has the type `_Bool'. */
-#undef HAVE__BOOL
-
/* Define to 1 if your compiler understands __builtin_bswap16. */
#undef HAVE__BUILTIN_BSWAP16
--
2.47.0
0002-Remove-obsolete-macOS-PPC-workaround.patch (text/x-patch, 1.1K) download
From 83a88c8147db8bfeafa38a4b609d2ea4961b6fe2 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Mon, 18 Nov 2024 13:48:46 +1300
Subject: [PATCH 2/2] Remove obsolete macOS/PPC workaround.
macOS/PPC, a paltform that ended with macOS 10.5 in 2009, was the last
known system where we didn't define PG_USE_STDBOOL. Defenses installed
by commit ff47d4bf aren't needed on modern systems and won't even make
sense when the C standard rolls forward and bool isn't a macro.
---
src/backend/utils/fmgr/dfmgr.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/src/backend/utils/fmgr/dfmgr.c b/src/backend/utils/fmgr/dfmgr.c
index c7aa789b51b..8e81ecc7491 100644
--- a/src/backend/utils/fmgr/dfmgr.c
+++ b/src/backend/utils/fmgr/dfmgr.c
@@ -18,16 +18,6 @@
#ifndef WIN32
#include <dlfcn.h>
-
-/*
- * On macOS, <dlfcn.h> insists on including <stdbool.h>. If we're not
- * using stdbool, undef bool to undo the damage.
- */
-#ifndef PG_USE_STDBOOL
-#ifdef bool
-#undef bool
-#endif
-#endif
#endif /* !WIN32 */
#include "fmgr.h"
--
2.47.0
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-18 01:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 09:27 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
1 sibling, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-18 01:59 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> I found a few lines we could just delete in master. I wonder if we
> should also just require sizeof(bool) == 1 more explicitly going
> forward with an error, since we don't have coverage or any expectation
> of ever getting any for the alternative code AFAICS, even if it is
> small.
Yeah, that's a fair criticism. I don't think we've tested that code
path since I retired prairiedog, so who's to say that it works even
now? Maybe it's best to just delete that code, and if we ever find a
new platform with wider bool, figure out what to do at that time.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-18 01:59 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-27 09:27 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-27 14:54 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-27 09:27 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Mon, Nov 18, 2024 at 2:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > I found a few lines we could just delete in master. I wonder if we
> > should also just require sizeof(bool) == 1 more explicitly going
> > forward with an error, since we don't have coverage or any expectation
> > of ever getting any for the alternative code AFAICS, even if it is
> > small.
>
> Yeah, that's a fair criticism. I don't think we've tested that code
> path since I retired prairiedog, so who's to say that it works even
> now? Maybe it's best to just delete that code, and if we ever find a
> new platform with wider bool, figure out what to do at that time.
Here's a draft patch for that.
Attachments:
0001-Require-sizeof-bool-1.patch (application/octet-stream, 11.6K) download
From 34dce524e487488ee0603d74d95ad31f81d3441b Mon Sep 17 00:00:00 2001
From: Thomas Munro <tmunro@postgresql.org>
Date: Wed, 27 Nov 2024 18:09:49 +1300
Subject: [PATCH] Require sizeof(bool) == 1.
The C standard says that sizeof(bool) is implementation-defined, but we
know of no current systems where it is not 1. The last known systems
seem to have been Apple macOS/PowerPC 10.5 and Microsoft Visual C++ 4,
both long defunct.
PostgreSQL has always required sizeof(bool) == 1 for the definition of
bool that it used, but previously it would define its own type if the
system-provided bool had a different size. That was always liable to
cause memory layout problems when interacting with system and
third-party libraries on (by now hypothetical) computers with wider
bool. C23 has now introduced a new problem by making bool a built in
datatype (like C++), so the fallback code doesn't even compile. We
could probably work around that, but then we'd be writing new untested
code for a computer that doesn't exist.
Instead, delete the unreachable and C23-uncompilable fallback code, and
let existing static assertions fail if the system-provided bool is too
wide. If we ever get a problem report from a real system, then it will
be time to figure out what to do about it in a way that also works on
modern compilers.
Note on C++: previously we avoided including <stdbool.h> or trying to
define a new bool type in headers included by C++ code. Now that the
latter is removed, we might as well just include <stdbool.h>
unconditionally: it should be visible to C++11 but do nothing, just as
in C23. We already include <stdint.h> without C++ guards in c.h, and
that falls under the same C99-compatibility section of the C++11
standard as <stdbool.h>, so let's remove the guards here too.
Reviewed-by:
Discussion: https://postgr.es/m/3198438.1731895163%40sss.pgh.pa.us
---
configure | 41 --------------------
configure.ac | 9 -----
meson.build | 7 ----
src/backend/jit/llvm/llvmjit_types.c | 8 ++--
src/backend/utils/fmgr/dfmgr.c | 10 -----
src/include/c.h | 30 +-------------
src/include/pg_config.h.in | 6 ---
src/interfaces/ecpg/include/ecpg_config.h.in | 3 --
src/interfaces/ecpg/include/ecpglib.h | 30 +-------------
src/interfaces/ecpg/include/meson.build | 1 -
src/pl/plperl/plperl_system.h | 23 +----------
11 files changed, 8 insertions(+), 160 deletions(-)
diff --git a/configure b/configure
index 199d666aa73..5470b863824 100755
--- a/configure
+++ b/configure
@@ -14958,47 +14958,6 @@ if test "$ac_cv_sizeof_off_t" -lt 8; then
fi
fi
-# The cast to long int works around a bug in the HP C Compiler
-# version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
-# declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
-# This bug is HP SR number 8606223364.
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking size of bool" >&5
-$as_echo_n "checking size of bool... " >&6; }
-if ${ac_cv_sizeof_bool+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- if ac_fn_c_compute_int "$LINENO" "(long int) (sizeof (bool))" "ac_cv_sizeof_bool" "#include <stdbool.h>
-"; then :
-
-else
- if test "$ac_cv_type_bool" = yes; then
- { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
-$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
-as_fn_error 77 "cannot compute sizeof (bool)
-See \`config.log' for more details" "$LINENO" 5; }
- else
- ac_cv_sizeof_bool=0
- fi
-fi
-
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_sizeof_bool" >&5
-$as_echo "$ac_cv_sizeof_bool" >&6; }
-
-
-
-cat >>confdefs.h <<_ACEOF
-#define SIZEOF_BOOL $ac_cv_sizeof_bool
-_ACEOF
-
-
-
-if test "$ac_cv_sizeof_bool" = 1; then
-
-$as_echo "#define PG_USE_STDBOOL 1" >>confdefs.h
-
-fi
-
##
## Functions, global variables
diff --git a/configure.ac b/configure.ac
index 4f56bb5062e..b792ab110a9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1691,15 +1691,6 @@ if test "$ac_cv_sizeof_off_t" -lt 8; then
fi
fi
-AC_CHECK_SIZEOF([bool], [], [#include <stdbool.h>])
-
-dnl We use <stdbool.h> if bool has size 1 after including it. Otherwise, c.h
-dnl will fall back to declaring bool as unsigned char.
-if test "$ac_cv_sizeof_bool" = 1; then
- AC_DEFINE([PG_USE_STDBOOL], 1,
- [Define to 1 to use <stdbool.h> to define type bool.])
-fi
-
##
## Functions, global variables
diff --git a/meson.build b/meson.build
index 83e61d0f4a8..1644600f5ef 100644
--- a/meson.build
+++ b/meson.build
@@ -1755,13 +1755,6 @@ if cc.compiles('''
endif
-# We use <stdbool.h> if bool has size 1 after including it. Otherwise, c.h
-# will fall back to declaring bool as unsigned char.
-if cc.sizeof('bool', prefix: '#include <stdbool.h>', args: test_c_args) == 1
- cdata.set('PG_USE_STDBOOL', 1)
-endif
-
-
# Need to check a call with %m because netbsd supports gnu_printf but emits a
# warning for each use of %m.
printf_attributes = ['gnu_printf', '__syslog__', 'printf']
diff --git a/src/backend/jit/llvm/llvmjit_types.c b/src/backend/jit/llvm/llvmjit_types.c
index 4a9e0770145..13efe18e6b0 100644
--- a/src/backend/jit/llvm/llvmjit_types.c
+++ b/src/backend/jit/llvm/llvmjit_types.c
@@ -117,11 +117,9 @@ ExecEvalBoolSubroutineTemplate(ExprState *state,
}
/*
- * Clang represents stdbool.h style booleans that are returned by functions
- * differently (as i1) than stored ones (as i8). Therefore we do not just need
- * TypeBool (above), but also a way to determine the width of a returned
- * integer. This allows us to keep compatible with non-stdbool using
- * architectures.
+ * Clang represents bool returned by functions differently (as i1) than stored
+ * ones (as i8). Therefore we do not just need TypeStorageBool (above), but
+ * also a way to determine the width of a returned integer.
*/
extern bool FunctionReturningBool(void);
bool
diff --git a/src/backend/utils/fmgr/dfmgr.c b/src/backend/utils/fmgr/dfmgr.c
index c7aa789b51b..8e81ecc7491 100644
--- a/src/backend/utils/fmgr/dfmgr.c
+++ b/src/backend/utils/fmgr/dfmgr.c
@@ -18,16 +18,6 @@
#ifndef WIN32
#include <dlfcn.h>
-
-/*
- * On macOS, <dlfcn.h> insists on including <stdbool.h>. If we're not
- * using stdbool, undef bool to undo the damage.
- */
-#ifndef PG_USE_STDBOOL
-#ifdef bool
-#undef bool
-#endif
-#endif
#endif /* !WIN32 */
#include "fmgr.h"
diff --git a/src/include/c.h b/src/include/c.h
index fe1ce87882b..304dff27e34 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ -450,37 +450,11 @@ typedef void (*pg_funcptr_t) (void);
* bool
* Boolean value, either true or false.
*
- * We use stdbool.h if bool has size 1 after including it. That's useful for
- * better compiler and debugger output and for compatibility with third-party
- * libraries. But PostgreSQL currently cannot deal with bool of other sizes;
- * there are static assertions around the code to prevent that.
- *
- * For C++ compilers, we assume the compiler has a compatible built-in
- * definition of bool.
- *
- * See also the version of this code in src/interfaces/ecpg/include/ecpglib.h.
+ * PostgreSQL currently cannot deal with bool of size other than 1; there are
+ * static assertions around the code to prevent that.
*/
-#ifndef __cplusplus
-
-#ifdef PG_USE_STDBOOL
#include <stdbool.h>
-#else
-
-#ifndef bool
-typedef unsigned char bool;
-#endif
-
-#ifndef true
-#define true ((bool) 1)
-#endif
-
-#ifndef false
-#define false ((bool) 0)
-#endif
-
-#endif /* not PG_USE_STDBOOL */
-#endif /* not C++ */
/* ----------------------------------------------------------------
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index 40e4b2e3816..7e578cc712c 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -600,9 +600,6 @@
/* Define to best printf format archetype, usually gnu_printf if available. */
#undef PG_PRINTF_ATTRIBUTE
-/* Define to 1 to use <stdbool.h> to define type bool. */
-#undef PG_USE_STDBOOL
-
/* PostgreSQL version as a string */
#undef PG_VERSION
@@ -633,9 +630,6 @@
RELSEG_SIZE requires an initdb. */
#undef RELSEG_SIZE
-/* The size of `bool', as computed by sizeof. */
-#undef SIZEOF_BOOL
-
/* The size of `long', as computed by sizeof. */
#undef SIZEOF_LONG
diff --git a/src/interfaces/ecpg/include/ecpg_config.h.in b/src/interfaces/ecpg/include/ecpg_config.h.in
index 2b439c1e58d..75f542f263b 100644
--- a/src/interfaces/ecpg/include/ecpg_config.h.in
+++ b/src/interfaces/ecpg/include/ecpg_config.h.in
@@ -6,6 +6,3 @@
/* Define to 1 if `long long int' works and is 64 bits. */
#undef HAVE_LONG_LONG_INT_64
-
-/* Define to 1 to use <stdbool.h> to define type bool. */
-#undef PG_USE_STDBOOL
diff --git a/src/interfaces/ecpg/include/ecpglib.h b/src/interfaces/ecpg/include/ecpglib.h
index 771761ffe49..dbf3cc3a0c2 100644
--- a/src/interfaces/ecpg/include/ecpglib.h
+++ b/src/interfaces/ecpg/include/ecpglib.h
@@ -7,6 +7,7 @@
#ifndef _ECPGLIB_H
#define _ECPGLIB_H
+#include <stdbool.h>
#include <string.h>
#include "ecpg_config.h"
@@ -14,35 +15,6 @@
#include "libpq-fe.h"
#include "sqlca.h"
-/*
- * This is a small extract from c.h since we don't want to leak all postgres
- * definitions into ecpg programs; but we need to know what bool is.
- */
-#ifndef __cplusplus
-
-#ifdef PG_USE_STDBOOL
-#include <stdbool.h>
-#else
-
-/*
- * We assume bool has been defined if true and false are. This avoids
- * duplicate-typedef errors if this file is included after c.h.
- */
-#if !(defined(true) && defined(false))
-typedef unsigned char bool;
-#endif
-
-#ifndef true
-#define true ((bool) 1)
-#endif
-
-#ifndef false
-#define false ((bool) 0)
-#endif
-
-#endif /* not PG_USE_STDBOOL */
-#endif /* not C++ */
-
#ifdef __cplusplus
extern "C"
diff --git a/src/interfaces/ecpg/include/meson.build b/src/interfaces/ecpg/include/meson.build
index b4a5aedd51f..a3beb3cc7be 100644
--- a/src/interfaces/ecpg/include/meson.build
+++ b/src/interfaces/ecpg/include/meson.build
@@ -5,7 +5,6 @@ ecpg_inc = include_directories('.')
ecpg_conf_keys = [
'HAVE_LONG_INT_64',
'HAVE_LONG_LONG_INT_64',
- 'PG_USE_STDBOOL',
]
ecpg_conf_data = configuration_data()
diff --git a/src/pl/plperl/plperl_system.h b/src/pl/plperl/plperl_system.h
index 48f6575e513..d1b9ea17fca 100644
--- a/src/pl/plperl/plperl_system.h
+++ b/src/pl/plperl/plperl_system.h
@@ -72,16 +72,10 @@
#endif
/*
- * Regarding bool, both PostgreSQL and Perl might use stdbool.h or not,
- * depending on configuration. If both agree, things are relatively harmless.
- * If not, things get tricky. If PostgreSQL does but Perl does not, define
- * HAS_BOOL here so that Perl does not redefine bool; this avoids compiler
- * warnings. If PostgreSQL does not but Perl does, we need to undefine bool
- * after we include the Perl headers; see below.
+ * Define HAS_BOOL here so that Perl does not redefine bool. We included
+ * <stdbool.h> in c.h.
*/
-#ifdef PG_USE_STDBOOL
#define HAS_BOOL 1
-#endif
/*
* Get the basic Perl API. We use PERL_NO_GET_CONTEXT mode so that our code
@@ -180,19 +174,6 @@
/* perl version and platform portability */
#include "ppport.h"
-/*
- * perl might have included stdbool.h. If we also did that earlier (see c.h),
- * then that's fine. If not, we probably rejected it for some reason. In
- * that case, undef bool and proceed with our own bool. (Note that stdbool.h
- * makes bool a macro, but our own replacement is a typedef, so the undef
- * makes ours visible again).
- */
-#ifndef PG_USE_STDBOOL
-#ifdef bool
-#undef bool
-#endif
-#endif
-
/* supply HeUTF8 if it's missing - ppport.h doesn't supply it, unfortunately */
#ifndef HeUTF8
#define HeUTF8(he) ((HeKLEN(he) == HEf_SVKEY) ? \
--
2.47.0
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-18 01:59 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 09:27 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-27 14:54 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lane @ 2024-11-27 14:54 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Nov 18, 2024 at 2:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, that's a fair criticism. I don't think we've tested that code
>> path since I retired prairiedog, so who's to say that it works even
>> now? Maybe it's best to just delete that code, and if we ever find a
>> new platform with wider bool, figure out what to do at that time.
> Here's a draft patch for that.
Passes an eyeball check, but I've not really tried to test it.
I suppose the only meaningful test is likely to be letting the
buildfarm loose on it.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-20 08:35 ` Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 42+ messages in thread
From: Peter Eisentraut @ 2024-11-20 08:35 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On 18.11.24 02:30, Thomas Munro wrote:
> On Mon, Nov 18, 2024 at 11:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thomas Munro <thomas.munro@gmail.com> writes:
>>> It sounds like we should stop using the old and broken
>>> AC_CHECK_HEADER_STDBOOL macro.
>>
>> Yeah, that's what I was imagining: assume that <stdbool.h> exists
>> and works, and check only to see if sizeof(bool) is acceptable.
>
> I think this is the minimal change, which I'd push back to 13 post-freeze.
Note that if we backpatch C23 support, we also need to backpatch at
least commits a67a49648d9 and d2b4b4c2259.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
@ 2024-11-20 15:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-20 15:32 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Peter Eisentraut <peter@eisentraut.org> writes:
> Note that if we backpatch C23 support, we also need to backpatch at
> least commits a67a49648d9 and d2b4b4c2259.
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.
We have a little bit of grace time before this needs to happen,
but perhaps not very much.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-21 07:23 ` Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Peter Eisentraut @ 2024-11-21 07:23 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On 20.11.24 16:32, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> Note that if we backpatch C23 support, we also need to backpatch at
>> least commits a67a49648d9 and d2b4b4c2259.
>
> 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.
Before that, you get a ton of warnings and errors related to the node
tree walker routines. This is presumably related to commit 1c27d16e6e5.
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.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
@ 2024-11-25 10:01 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-25 10:01 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
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...
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-25 15:57 ` Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Peter Eisentraut @ 2024-11-25 15:57 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On 25.11.24 11:01, Thomas Munro wrote:
>> 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...
Where does this leave us regarding backpatching the other two
C23-related patches? The node tree walker issue looks like a very hard
barrier. I don't want to spend too much effort backpatching anything to
ancient version if there's little hope of getting the whole thing working.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
@ 2024-11-25 19:51 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-25 19:51 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Tue, Nov 26, 2024 at 4:57 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> Where does this leave us regarding backpatching the other two
> C23-related patches? The node tree walker issue looks like a very hard
> barrier. I don't want to spend too much effort backpatching anything to
> ancient version if there's little hope of getting the whole thing working.
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 <stdbool.h> 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?
Coincidental observation: We added -Wdeprecated-non-prototype back
when Clang 15 invented it, but I noticed that GCC 15 has just now
added it too[1], so alligator started detecting and using that in
REL_15_STABLE last week. Of course it doesn't help once you're
talking C23.
[1] https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=701d8e7e60b85809cae348c1e9edb3b0f4924325
[2] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=alligator&dt=2024-11-18%2019%3A23%...
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-25 20:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-25 20:07 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> 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 <stdbool.h> 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 <stdbool.h> 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
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-26 02:03 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-26 02:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
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...
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.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-26 02:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-26 02:13 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> ... 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
Sounds plausible to me. Will you work on making that happen?
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-26 02:25 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-26 02:25 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Tue, Nov 26, 2024 at 3:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sounds plausible to me. Will you work on making that happen?
OK, trying it out...
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-26 11:24 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-26 11:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Tue, Nov 26, 2024 at 3:25 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Nov 26, 2024 at 3:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Sounds plausible to me. Will you work on making that happen?
>
> OK, trying it out...
Attached first attempt seems to work OK, tested on 9.2 and 15
branches. I'm not sure if it's the best way to test, or in the best
place, etc, ideas welcome. The reason for testing with > 201710
rather than >= 202311 is that there are some funny in between numbers
floating around: gcc14 -std=c23 -> 202000 (since you mentioned you'd
tested with that before), while gcc15 -std=c23 -> 202311 (the real
final standard number). Also tested v15 with clang18 -std=c23, which
breaks, and is fixed, as expected.
Attachments: download all (2 files, .tar.gz)
v1-15-0001-If-a-C23-compiler-is-detected-try-asking-for-C.patch (application/octet-stream, 4.4K) download
From e9bc15db2438282ae9c1bf692c22c0f2ada83404 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Tue, 26 Nov 2024 22:22:51 +1300
Subject: [PATCH v1-15] If a C23 compiler is detected, try asking for C17.
Branches before 16 can't be compiled with a C23 compiler (see
deprecation warnings silenced by commit f9a56e72, and non-back-patchable
changes made in 16 by comit 1c27d16e). Test __STDC_VERSION__, and if
it's above C17 then try appending -std=gnu17. The test is done with the
user's CFLAGS, so an acceptable language version can also be configured
manually there.
This is done in branches 15 and older, back to 9.2, per policy of
keeping them buildable with modern tools.
Discussion: https://postgr.es/m/87o72eo9iu.fsf%40gentoo.org
---
configure | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++
configure.ac | 20 ++++++++++++++
2 files changed, 97 insertions(+)
diff --git a/configure b/configure
index fce7df1ac83..72f50ee575f 100755
--- a/configure
+++ b/configure
@@ -5284,6 +5284,83 @@ else
BITCODE_CXXFLAGS="-O2 $BITCODE_CXXFLAGS"
fi
+# We use C constructs that became in invalid in C23. Check if the compiler
+# reports a standard higher than C17, with the flags selected above (so the
+# user can control the language level explicitly to avoid the gcc/clang-only
+# fallback logic below if preferred).
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC reports a C standard higher than ISO C17" >&5
+$as_echo_n "checking whether $CC reports a C standard higher than ISO C17... " >&6; }
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+#if __STDC_VERSION__ > 201710L
+choke me
+#endif
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ POSTC17=no
+else
+ POSTC17=yes
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: ${POSTC17}" >&5
+$as_echo "${POSTC17}" >&6; }
+
+# If a too recent standard was detected with the user's CFLAGS, try asking for
+# C17 with GNU extensions explicitly.
+if test "$POSTC17" = yes; then
+ old_CFLAGS="$CFLAGS"
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -std=gnu17, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -std=gnu17, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__std_gnu17+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -std=gnu17"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ pgac_cv_prog_CC_cflags__std_gnu17=yes
+else
+ pgac_cv_prog_CC_cflags__std_gnu17=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__std_gnu17" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__std_gnu17" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__std_gnu17" = x"yes"; then
+ CFLAGS="${CFLAGS} -std=gnu17"
+fi
+
+
+ if test "$CFLAGS" = "$old_CFLAGS"; then
+ as_fn_error $? "cannot proceed" "$LINENO" 5
+ fi
+fi
+
# C[XX]FLAGS we determined above will be added back at the end
user_CFLAGS=$CFLAGS
CFLAGS=""
diff --git a/configure.ac b/configure.ac
index 00b91ab2c3e..ad360bdba34 100644
--- a/configure.ac
+++ b/configure.ac
@@ -459,6 +459,26 @@ else
BITCODE_CXXFLAGS="-O2 $BITCODE_CXXFLAGS"
fi
+# We use C constructs that became in invalid in C23. Check if the compiler
+# reports a standard higher than C17, with the flags selected above (so the
+# user can control the language level explicitly to avoid the gcc/clang-only
+# fallback logic below if preferred).
+AC_MSG_CHECKING([whether $CC reports a C standard higher than ISO C17])
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@if __STDC_VERSION__ > 201710L
+choke me
+@%:@endif])], [POSTC17=no], [POSTC17=yes])
+AC_MSG_RESULT(${POSTC17})
+
+# If a too recent standard was detected with the user's CFLAGS, try asking for
+# C17 with GNU extensions explicitly.
+if test "$POSTC17" = yes; then
+ old_CFLAGS="$CFLAGS"
+ PGAC_PROG_CC_CFLAGS_OPT([-std=gnu17])
+ if test "$CFLAGS" = "$old_CFLAGS"; then
+ AC_MSG_ERROR([cannot proceed])
+ fi
+fi
+
# C[XX]FLAGS we determined above will be added back at the end
user_CFLAGS=$CFLAGS
CFLAGS=""
--
2.47.0
v1-9.2-0001-If-a-C23-compiler-is-detected-try-asking-for-.patch (application/octet-stream, 5.9K) download
From aa05346d645547ce6d1189d33405418f3af729c0 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Tue, 26 Nov 2024 23:53:31 +1300
Subject: [PATCH v1-9.2] If a C23 compiler is detected, try asking for C17.
Branches before 16 can't be compiled with a C23 compiler (see
deprecation warnings silenced by commit f9a56e72, and non-back-patchable
changes made in 16 by comit 1c27d16e). Test __STDC_VERSION__, and if
it's above C17 then try appending -std=gnu17. The test is done with the
user's CFLAGS, so an acceptable language version can also be configured
manually there.
This is done in branches 15 and older, back to 9.2, per policy of
keeping them buildable with modern tools.
Discussion: https://postgr.es/m/87o72eo9iu.fsf%40gentoo.org
---
configure | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++
configure.in | 20 +++++++++
2 files changed, 144 insertions(+)
diff --git a/configure b/configure
index ba520952fd2..fec0dd3d310 100755
--- a/configure
+++ b/configure
@@ -3975,6 +3975,130 @@ else
fi
fi
+# We use C constructs that became in invalid in C23. Check if the compiler
+# reports a standard higher than C17, with the flags selected above (so the
+# user can control the language level explicitly to avoid the gcc/clang-only
+# fallback logic below if preferred).
+{ $as_echo "$as_me:$LINENO: checking whether $CC reports a C standard higher than ISO C17" >&5
+$as_echo_n "checking whether $CC reports a C standard higher than ISO C17... " >&6; }
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+int
+main ()
+{
+#if __STDC_VERSION__ > 201710L
+choke me
+#endif
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try="$ac_compile"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
+$as_echo "$ac_try_echo") >&5
+ (eval "$ac_compile") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest.$ac_objext; then
+ POSTC17=no
+else
+ $as_echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ POSTC17=yes
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+{ $as_echo "$as_me:$LINENO: result: ${POSTC17}" >&5
+$as_echo "${POSTC17}" >&6; }
+
+# If a too recent standard was detected with the user's CFLAGS, try asking for
+# C17 with GNU extensions explicitly.
+if test "$POSTC17" = yes; then
+ old_CFLAGS="$CFLAGS"
+ { $as_echo "$as_me:$LINENO: checking whether $CC supports -std=gnu17" >&5
+$as_echo_n "checking whether $CC supports -std=gnu17... " >&6; }
+if test "${pgac_cv_prog_cc_cflags__std_gnu17+set}" = set; then
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+CFLAGS="$pgac_save_CFLAGS -std=gnu17"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (ac_try="$ac_compile"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
+$as_echo "$ac_try_echo") >&5
+ (eval "$ac_compile") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest.$ac_objext; then
+ pgac_cv_prog_cc_cflags__std_gnu17=yes
+else
+ $as_echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ pgac_cv_prog_cc_cflags__std_gnu17=no
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+fi
+{ $as_echo "$as_me:$LINENO: result: $pgac_cv_prog_cc_cflags__std_gnu17" >&5
+$as_echo "$pgac_cv_prog_cc_cflags__std_gnu17" >&6; }
+if test x"$pgac_cv_prog_cc_cflags__std_gnu17" = x"yes"; then
+ CFLAGS="$CFLAGS -std=gnu17"
+fi
+
+ if test "$CFLAGS" = "$old_CFLAGS"; then
+ { { $as_echo "$as_me:$LINENO: error: cannot proceed" >&5
+$as_echo "$as_me: error: cannot proceed" >&2;}
+ { (exit 1); exit 1; }; }
+ fi
+fi
+
# Some versions of GCC support some additional useful warning flags.
# Check whether they are supported, and add them to CFLAGS if so.
# ICC pretends to be GCC but it's lying; it doesn't support these flags,
diff --git a/configure.in b/configure.in
index 93d62944db6..b1abc3a5dc8 100644
--- a/configure.in
+++ b/configure.in
@@ -407,6 +407,26 @@ else
fi
fi
+# We use C constructs that became in invalid in C23. Check if the compiler
+# reports a standard higher than C17, with the flags selected above (so the
+# user can control the language level explicitly to avoid the gcc/clang-only
+# fallback logic below if preferred).
+AC_MSG_CHECKING([whether $CC reports a C standard higher than ISO C17])
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@if __STDC_VERSION__ > 201710L
+choke me
+@%:@endif])], [POSTC17=no], [POSTC17=yes])
+AC_MSG_RESULT(${POSTC17})
+
+# If a too recent standard was detected with the user's CFLAGS, try asking for
+# C17 with GNU extensions explicitly.
+if test "$POSTC17" = yes; then
+ old_CFLAGS="$CFLAGS"
+ PGAC_PROG_CC_CFLAGS_OPT([-std=gnu17])
+ if test "$CFLAGS" = "$old_CFLAGS"; then
+ AC_MSG_ERROR([cannot proceed])
+ fi
+fi
+
# Some versions of GCC support some additional useful warning flags.
# Check whether they are supported, and add them to CFLAGS if so.
# ICC pretends to be GCC but it's lying; it doesn't support these flags,
--
2.47.0
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-27 04:50 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Thomas Munro @ 2024-11-27 04:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Pushed. Alligator is turning green in the back branches, only one more to go.
I see that Peter also pushed the reserved word patches. Apparently
that gcc bug it's blowing up on might go away with -g0 (see link
earlier), but anyway it's a nightly build compiler so fingers crossed
for a fix soon. The newer branches are building and running for me on
{ gcc14, gcc15, clang18 } -std=gnu23, and apparently the bug was even
in gcc14, so it must require some unlikely conditions that alligator
has stumbled on.
(Yeah I had missed 10, thanks for the nudge.)
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-27 18:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-27 18:28 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; tharakan@gmail.com, Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> Pushed. Alligator is turning green in the back branches, only one more to go.
> I see that Peter also pushed the reserved word patches. Apparently
> that gcc bug it's blowing up on might go away with -g0 (see link
> earlier), but anyway it's a nightly build compiler so fingers crossed
> for a fix soon. The newer branches are building and running for me on
> { gcc14, gcc15, clang18 } -std=gnu23, and apparently the bug was even
> in gcc14, so it must require some unlikely conditions that alligator
> has stumbled on.
Looks like flaviventris and serinus just updated to the same broken
compiler version that alligator is using :-(. Maybe we'd better
file a formal bug report?
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-27 18:50 ` Andres Freund <andres@anarazel.de>
2024-11-27 19:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 42+ messages in thread
From: Andres Freund @ 2024-11-27 18:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; tharakan@gmail.com, Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Hi,
On 2024-11-27 13:28:24 -0500, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Pushed. Alligator is turning green in the back branches, only one more to go.
> > I see that Peter also pushed the reserved word patches. Apparently
> > that gcc bug it's blowing up on might go away with -g0 (see link
> > earlier), but anyway it's a nightly build compiler so fingers crossed
> > for a fix soon. The newer branches are building and running for me on
> > { gcc14, gcc15, clang18 } -std=gnu23, and apparently the bug was even
> > in gcc14, so it must require some unlikely conditions that alligator
> > has stumbled on.
>
> Looks like flaviventris and serinus just updated to the same broken
> compiler version that alligator is using :-(. Maybe we'd better
> file a formal bug report?
I run a development gcc locally, and I just had updated it this morning
(4a868591169). Interestingly I don't see the ICE with it.
But I can reproduce it with debian sid's gcc-snapshot, with exactly the same
compiler arguments. The snapshot's version:
gcc (Debian 20241123-1) 15.0.0 20241123 (experimental) [master r15-5606-g4aa4162e365]
so it looks like the bug might have been fixed recently?
I'm not sure this is really the bug linked to earlier [1]. I can't repro the
issue with 14, for example.
It's possible it requires specific gcc configure flags to be triggered?
Luckily -g1 does, at least locally, work around the issue with
gcc-snapshot. So I guess I'll make flaviventris and serinus use that for now
:/
Greetings,
Andres Freund
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
@ 2024-11-27 19:01 ` Sam James <sam@gentoo.org>
2024-11-27 19:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 42+ messages in thread
From: Sam James @ 2024-11-27 19:01 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; tharakan@gmail.com, Peter Eisentraut <peter@eisentraut.org>; pgsql-bugs@lists.postgresql.org
Andres Freund <andres@anarazel.de> writes:
> Hi,
>
> On 2024-11-27 13:28:24 -0500, Tom Lane wrote:
>> Thomas Munro <thomas.munro@gmail.com> writes:
>> > Pushed. Alligator is turning green in the back branches, only one more to go.
>> > I see that Peter also pushed the reserved word patches. Apparently
>> > that gcc bug it's blowing up on might go away with -g0 (see link
>> > earlier), but anyway it's a nightly build compiler so fingers crossed
>> > for a fix soon. The newer branches are building and running for me on
>> > { gcc14, gcc15, clang18 } -std=gnu23, and apparently the bug was even
>> > in gcc14, so it must require some unlikely conditions that alligator
>> > has stumbled on.
>>
>> Looks like flaviventris and serinus just updated to the same broken
>> compiler version that alligator is using :-(. Maybe we'd better
>> file a formal bug report?
>
> I run a development gcc locally, and I just had updated it this morning
> (4a868591169). Interestingly I don't see the ICE with it.
>
> But I can reproduce it with debian sid's gcc-snapshot, with exactly the same
> compiler arguments. The snapshot's version:
> gcc (Debian 20241123-1) 15.0.0 20241123 (experimental) [master r15-5606-g4aa4162e365]
>
> so it looks like the bug might have been fixed recently?
>
> I'm not sure this is really the bug linked to earlier [1]. I can't repro the
> issue with 14, for example.
>
> It's possible it requires specific gcc configure flags to be triggered?
>
> Luckily -g1 does, at least locally, work around the issue with
> gcc-snapshot. So I guess I'll make flaviventris and serinus use that for now
> :/
>
> Greetings,
>
> Andres Freund
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
See https://gcc.gnu.org/PR117724 as well. The issues are related in that
canonicalisation of struct types keeps needing revisiting, more so in
light of C23 changes.
Note also that the ICE is only with "checking" (~assertions) which is
enabled at a stricter level for non-releases by default, so some of it
may affect 14 but not show up there.
Martin Uecker has posted a patch which is currently being reviewed. I
wouldn't worry about it until that lands unless the build failures continue.
thanks,
sam
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
@ 2024-11-27 19:21 ` Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 42+ messages in thread
From: Andres Freund @ 2024-11-27 19:21 UTC (permalink / raw)
To: Sam James <sam@gentoo.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; tharakan@gmail.com, Peter Eisentraut <peter@eisentraut.org>; pgsql-bugs@lists.postgresql.org
Hi,
On 2024-11-27 19:01:36 +0000, Sam James wrote:
> > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
> See https://gcc.gnu.org/PR117724 as well. The issues are related in that
> canonicalisation of struct types keeps needing revisiting, more so in
> light of C23 changes.
Thanks.
> Note also that the ICE is only with "checking" (~assertions) which is
> enabled at a stricter level for non-releases by default, so some of it
> may affect 14 but not show up there.
Ah, that explains that.
> Martin Uecker has posted a patch which is currently being reviewed. I
> wouldn't worry about it until that lands unless the build failures continue.
I changed my local build to use the same --checking as debian's gcc-snapshot,
confirmed that that reproduces the issue. Then applied Martin's patch. It does
fix the problem.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
@ 2024-11-27 19:32 ` Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
1 sibling, 1 reply; 42+ messages in thread
From: Andres Freund @ 2024-11-27 19:32 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; tharakan@gmail.com, Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Hi,
On 2024-11-27 13:50:59 -0500, Andres Freund wrote:
> Luckily -g1 does, at least locally, work around the issue with
> gcc-snapshot. So I guess I'll make flaviventris and serinus use that for now
> :/
Done. It did fix flaviventris/HEAD, I'm sure the others will follow soon.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
@ 2024-11-29 06:26 ` Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Robins Tharakan @ 2024-11-29 06:26 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Hi,
> Done. It did fix flaviventris/HEAD, I'm sure the others will follow soon.
alligator/HEAD is still failing though.
Let me know if changing something on alligator can help in some way.
-
robins
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-11-29 15:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-11-29 15:31 UTC (permalink / raw)
To: Robins Tharakan <tharakan@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Robins Tharakan <tharakan@gmail.com> writes:
> alligator/HEAD is still failing though.
> Let me know if changing something on alligator can help in some way.
I think we're waiting on the gcc crew to fix their bug. As long
as alligator is faithfully rebuilding gcc from upstream everyday,
there's not much more to do than wait.
(You could adopt Andres' -g1 workaround, but then we'd not know
when the gcc bug is fixed. So unless this drags on quite awhile,
I think alligator is best left as-is.)
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-12-07 11:42 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Robins Tharakan @ 2024-12-07 11:42 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Sat, 30 Nov 2024 at 02:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robins Tharakan <tharakan@gmail.com> writes:
> > alligator/HEAD is still failing though.
> > Let me know if changing something on alligator can help in some way.
>
> I think we're waiting on the gcc crew to fix their bug. As long
> as alligator is faithfully rebuilding gcc from upstream everyday,
> there's not much more to do than wait.
>
> (You could adopt Andres' -g1 workaround, but then we'd not know
> when the gcc bug is fixed. So unless this drags on quite awhile,
> I think alligator is best left as-is.)
>
It's been a few days since alligator lit up the buildfarm red. IMHO at this
point, it is just noise. So I've reduced its v16+ build frequency to daily
(instead of a few minutes). I'll revert that once gcc is fixed upstream.
-
robins
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-12-13 01:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-12-13 01:21 UTC (permalink / raw)
To: Robins Tharakan <tharakan@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Robins Tharakan <tharakan@gmail.com> writes:
> It's been a few days since alligator lit up the buildfarm red. IMHO at this
> point, it is just noise. So I've reduced its v16+ build frequency to daily
> (instead of a few minutes). I'll revert that once gcc is fixed upstream.
Looks like alligator just went green with the 20241212 gcc build.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-12-13 02:01 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Robins Tharakan @ 2024-12-13 02:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Fri, 13 Dec 2024 at 11:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robins Tharakan <tharakan@gmail.com> writes:
> > It's been a few days since alligator lit up the buildfarm red. IMHO at
> this
> > point, it is just noise. So I've reduced its v16+ build frequency to
> daily
> > (instead of a few minutes). I'll revert that once gcc is fixed upstream.
>
> Looks like alligator just went green with the 20241212 gcc build.
>
Nice! Just forced REL_17_STABLE / REL_16_STABLE and they are past
that failure point too (still running).
For now I've restored the original build frequency for these branches.
-
robins
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-12-13 02:16 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 03:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 42+ messages in thread
From: Robins Tharakan @ 2024-12-13 02:16 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Fri, 13 Dec 2024 at 12:31, Robins Tharakan <tharakan@gmail.com> wrote:
> Just forced REL_17_STABLE / REL_16_STABLE and they are past
> that failure point too (still running).
>
>
Seems unrelated to the thread but v17 has failed.
REL_17_STABLE failed on misc-recovery and one context I can add here is
that I triggered both REL_16_STABLE and REL_17_STABLE together and
were running neck-and-neck wherein v16 went past this test (in ~4 minutes)
and v17 (got stuck for ~10 min) and failed.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2024-12-13%2001%3A24%3A58
-
robins
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-12-13 02:31 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 13:48 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andrew Dunstan <andrew@dunslane.net>
1 sibling, 1 reply; 42+ messages in thread
From: Robins Tharakan @ 2024-12-13 02:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Fri, 13 Dec 2024 at 12:46, Robins Tharakan <tharakan@gmail.com> wrote:
>
> REL_17_STABLE failed on misc-recovery and one context I can add here is
> that I triggered both REL_16_STABLE and REL_17_STABLE together and
> were running neck-and-neck wherein v16 went past this test (in ~4 minutes)
> and v17 (got stuck for ~10 min) and failed.
>
>
Is it possible that 2 concurrent runs (of different branches) could step on
each other?
These are the logs that I captured, and v16 [2] / v17 [1] literally ran at
the same
time (seconds apart).
v16 log:
alligator:REL_16_STABLE [12:24:42] running bin test scripts ...
alligator:REL_16_STABLE [12:25:28] running test misc-recovery ...
alligator:REL_16_STABLE [12:29:40] running test misc-subscription ...
v17 log:
alligator:REL_17_STABLE [12:25:09] running bin test psql ...
alligator:REL_17_STABLE [12:25:19] running bin test scripts ...
alligator:REL_17_STABLE [12:26:00] running test misc-recovery ...
alligator:REL_17_STABLE [12:37:15] failed at stage recoveryCheck
$
Anyway, I have triggered another v17 run. If the above was purely
coincidental, then
that run should fail too.
Ref:
1. v17:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2024-12-13%2001%3A24%3A58
2. v16:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=alligator&dt=2024-12-13%2001%3A25%...
-
robins
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-12-13 13:48 ` Andrew Dunstan <andrew@dunslane.net>
2024-12-14 10:46 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Andrew Dunstan @ 2024-12-13 13:48 UTC (permalink / raw)
To: Robins Tharakan <tharakan@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On 2024-12-12 Th 9:31 PM, Robins Tharakan wrote:
>
> On Fri, 13 Dec 2024 at 12:46, Robins Tharakan <tharakan@gmail.com> wrote:
>
>
> REL_17_STABLE failed on misc-recovery and one context I can add
> here is
> that I triggered both REL_16_STABLE and REL_17_STABLE together and
> were running neck-and-neck wherein v16 went past this test (in ~4
> minutes)
> and v17 (got stuck for ~10 min) and failed.
>
>
> Is it possible that 2 concurrent runs (of different branches) could
> step on each other?
>
> These are the logs that I captured, and v16 [2] / v17 [1] literally
> ran at the same
> time (seconds apart).
>
>
> v16 log:
> alligator:REL_16_STABLE [12:24:42] running bin test scripts ...
> alligator:REL_16_STABLE [12:25:28] running test misc-recovery ...
> alligator:REL_16_STABLE [12:29:40] running test misc-subscription ...
>
>
> v17 log:
> alligator:REL_17_STABLE [12:25:09] running bin test psql ...
> alligator:REL_17_STABLE [12:25:19] running bin test scripts ...
> alligator:REL_17_STABLE [12:26:00] running test misc-recovery ...
> alligator:REL_17_STABLE [12:37:15] failed at stage recoveryCheck
> $
>
We actually have a good deal of protection against concurrent runs
clobbering each other.
It's not clear to me if you're using "run_branches.pl --run-parallel" or
not. If not, you might like to consider changing to that - it's the
recommended way of doing concurrent runs. Apart from any other reason it
removes the need for a lot of redundant git fetches. By default it
staggers concurrent build starts by 60 seconds.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 13:48 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andrew Dunstan <andrew@dunslane.net>
@ 2024-12-14 10:46 ` Robins Tharakan <tharakan@gmail.com>
2024-12-14 17:04 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Robins Tharakan @ 2024-12-14 10:46 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Sat, 14 Dec 2024 at 00:18, Andrew Dunstan <andrew@dunslane.net> wrote:
> We actually have a good deal of protection against concurrent runs
> clobbering each other.
>
> It's not clear to me if you're using "run_branches.pl --run-parallel" or
> not. If not, you might like to consider changing to that - it's the
> recommended way of doing concurrent runs. Apart from any other reason it
> removes the need for a lot of redundant git fetches. By default it staggers
> concurrent build starts by 60 seconds.
>
>
In this case I didn't use run_branches.pl. I just opened up two sessions
and triggered two
separate runs for v16 / v17 (with --force) since master just came out
green. Efficiency aside,
at worst I was expecting two concurrent runs to be slower, but not error
out.
Unrelated, for a slow system my understanding was that it's quite
inefficient to keep running older
branches every few minutes (like HEAD does) - so for some of the animals I
explicitly run older
branches (for e.g. v13) every few hours, but HEAD runs every few minutes.
Are you saying it's still a good idea to run all together every few minutes
(and let older branches
skip if there's nothing to do)?
-
robins
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 13:48 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andrew Dunstan <andrew@dunslane.net>
2024-12-14 10:46 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-12-14 17:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-15 07:04 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2024-12-14 17:04 UTC (permalink / raw)
To: Robins Tharakan <tharakan@gmail.com>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Robins Tharakan <tharakan@gmail.com> writes:
> Unrelated, for a slow system my understanding was that it's quite
> inefficient to keep running older
> branches every few minutes (like HEAD does) - so for some of the animals I
> explicitly run older
> branches (for e.g. v13) every few hours, but HEAD runs every few minutes.
> Are you saying it's still a good idea to run all together every few minutes
> (and let older branches
> skip if there's nothing to do)?
Nowadays run_branches' check for whether there's something to do is
cheap enough that it's not worth skipping. So it's recommendable
to just launch that every so often, and not complicate your life
with manual per-branch scheduling.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 13:48 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andrew Dunstan <andrew@dunslane.net>
2024-12-14 10:46 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-14 17:04 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-12-15 07:04 ` Robins Tharakan <tharakan@gmail.com>
2024-12-19 02:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Robins Tharakan @ 2024-12-15 07:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Sun, 15 Dec 2024 at 03:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Nowadays run_branches' check for whether there's something to do is
> cheap enough that it's not worth skipping. So it's recommendable
> to just launch that every so often, and not complicate your life
> with manual per-branch scheduling.
>
Thanks for explaining / confirming.
I'll update the remaining machine configurations soon.
-
robins
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 13:48 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andrew Dunstan <andrew@dunslane.net>
2024-12-14 10:46 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-14 17:04 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-15 07:04 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-12-19 02:45 ` Thomas Munro <thomas.munro@gmail.com>
0 siblings, 0 replies; 42+ messages in thread
From: Thomas Munro @ 2024-12-19 02:45 UTC (permalink / raw)
To: Robins Tharakan <tharakan@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Andrew Dunstan <andrew@dunslane.net>; Andres Freund <andres@anarazel.de>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
On Sun, Dec 15, 2024 at 8:04 PM Robins Tharakan <tharakan@gmail.com> wrote:
> [unexplained failure on alligator]
2024-12-19 12:38:26.223 ACDT [1956030:2] [unknown] FATAL: could not
open shared memory segment "/PostgreSQL.2167569412": No such file or
directory
That smells like systemd's RemoteIPC feature:
https://www.postgresql.org/docs/current/kernel-resources.html#SYSTEMD-REMOVEIPC
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Build failure with GCC 15 (defaults to -std=gnu23)
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-20 08:35 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Re: Build failure with GCC 15 (defaults to -std=gnu23) Robins Tharakan <tharakan@gmail.com>
@ 2024-12-13 03:42 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 42+ messages in thread
From: Tom Lane @ 2024-12-13 03:42 UTC (permalink / raw)
To: Robins Tharakan <tharakan@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; Thomas Munro <thomas.munro@gmail.com>; Peter Eisentraut <peter@eisentraut.org>; Sam James <sam@gentoo.org>; pgsql-bugs@lists.postgresql.org
Robins Tharakan <tharakan@gmail.com> writes:
> Is it possible that 2 concurrent runs (of different branches) could step on
> each other?
Looks that way, doesn't it? But I suspect it's just a timing
problem --- perhaps one triggered by the background load caused
by another test run, but not directly related to it. Looking at
019_replslot_limit.pl, I see
-----
# freeze walsender and walreceiver. Slot will still be active, but walreceiver
# won't get anything anymore.
kill 'STOP', $senderpid, $receiverpid;
$node_primary3->advance_wal(2);
-----
This fragment seems to assume that the effect of the kill 'STOP'
is instantaneous. If it's not, it seems possible that the
walsender process could manage to push out the WAL data added by
"advance_wal" before it gets frozen, in which case the subsequent
loop that's watching for it to get killed would watch in vain,
which matches your symptoms.
As far as a quick grep finds, this is the only test we have that
relies on kill 'STOP'. I suspect that it's too clever for its
own good.
I trawled the last three months' worth of buildfarm logs and
didn't find any other matches to "not ok 19 - walsender termination
logged". So this is a pretty improbable failure mode, whatever
the explanation is.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
end of thread, other threads:[~2024-12-19 02:45 UTC | newest]
Thread overview: 42+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-17 02:54 Build failure with GCC 15 (defaults to -std=gnu23) Sam James <sam@gentoo.org>
2024-11-17 18:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 19:30 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-17 20:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 21:18 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-17 21:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-17 22:45 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-17 22:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-18 01:30 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-18 01:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 09:27 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-27 14:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:35 ` Peter Eisentraut <peter@eisentraut.org>
2024-11-20 15:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-21 07:23 ` Peter Eisentraut <peter@eisentraut.org>
2024-11-25 10:01 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-25 15:57 ` Peter Eisentraut <peter@eisentraut.org>
2024-11-25 19:51 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-25 20:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:03 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-26 02:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-26 02:25 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-26 11:24 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-27 04:50 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-27 18:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 18:50 ` Andres Freund <andres@anarazel.de>
2024-11-27 19:01 ` Sam James <sam@gentoo.org>
2024-11-27 19:21 ` Andres Freund <andres@anarazel.de>
2024-11-27 19:32 ` Andres Freund <andres@anarazel.de>
2024-11-29 06:26 ` Robins Tharakan <tharakan@gmail.com>
2024-11-29 15:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-07 11:42 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 01:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-13 02:01 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:16 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 02:31 ` Robins Tharakan <tharakan@gmail.com>
2024-12-13 13:48 ` Andrew Dunstan <andrew@dunslane.net>
2024-12-14 10:46 ` Robins Tharakan <tharakan@gmail.com>
2024-12-14 17:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-15 07:04 ` Robins Tharakan <tharakan@gmail.com>
2024-12-19 02:45 ` Thomas Munro <thomas.munro@gmail.com>
2024-12-13 03:42 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox