Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vRDeU-009pUc-1I for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Dec 2025 18:02:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vRDeT-003wZQ-1W for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Dec 2025 18:02:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vRDeT-003wZI-0b for pgsql-hackers@lists.postgresql.org; Thu, 04 Dec 2025 18:02:01 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vRDeR-0038uO-15 for pgsql-hackers@lists.postgresql.org; Thu, 04 Dec 2025 18:02:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5B4I1vcG1126763 for ; Thu, 4 Dec 2025 13:01:57 -0500 From: Tom Lane To: pgsql-hackers@lists.postgresql.org Subject: Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE In-reply-to: <986485.1764825548@sss.pgh.pa.us> References: <986485.1764825548@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 04 Dec 2025 00:19:08 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1126761.1764871317.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 04 Dec 2025 13:01:57 -0500 Message-ID: <1126762.1764871317@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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=3D] > 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' =3D> { 'CC' =3D> '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