From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE
Date: Thu, 04 Dec 2025 13:01:57 -0500
Message-ID: <1126762.1764871317@sss.pgh.pa.us> (raw)
In-Reply-To: <986485.1764825548@sss.pgh.pa.us>
References: <986485.1764825548@sss.pgh.pa.us>
I wrote:
> Currently, configure tries "gnu_printf" then "__syslog__" then
> "printf" to set PG_PRINTF_ATTRIBUTE. Of late, buildfarm member
> fritillary has been issuing warnings like
> ../../../../src/include/c.h:234:83: warning: 'syslog' is an unrecognized format function type [-Wformat=]
> I hadn't gotten around to looking at that closely, but in the past
> week three new animals (borer, skeletonizer, whitefly) have started
> doing that too. On inspection, I realize that that's not happening
> across our entire tree, but only within src/backend/jit/llvm.
Okay, I've figured out what's going on here, and it's not really
a new problem. The proximate cause is that these four animals are
set up to explicitly pick clang:
'config_env' => {
'CC' => 'clang'
},
but they are not forcing the choice of C++ compiler, and configure
just defaults that to "g++".
Although clang claims to support the same format attributes as
gcc (in fact, its documentation merely refers you to gcc's docs),
that is a flat-out lie. It has never supported "gnu_printf".
It does support "__syslog__" ... which gcc doesn't, at least
on Linux, and never has.
Thus, what's happening is that configure chooses PG_PRINTF_ATTRIBUTE
based on what the CC compiler likes, and then when we build C++ code
with the CXX compiler, it complains.
So if we don't want to see these warnings, either we need to try
to use the C++ compiler matching the CC choice, or we need to make
PG_PRINTF_ATTRIBUTE language-sensitive. I think it should work
to do two configure probes and then make c.h do something like
#ifdef __cplusplus
#define PG_PRINTF_ATTRIBUTE PG_CPP_PRINTF_ATTRIBUTE
#else
#define PG_PRINTF_ATTRIBUTE PG_C_PRINTF_ATTRIBUTE
#endif
On the other hand, aligning the C++ compiler with the C compiler
is likely to avoid other problems, so maybe it's better to focus
on making that happen. I'm not sure how we'd do that automatically
though.
For the moment we could silence the buildfarm noise by pressing
Mark W. to fix the configurations on these BF animals, which
is surely a lot less work than finding an automatic solution.
Thoughts?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE
In-Reply-To: <1126762.1764871317@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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