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 1w1ppy-000e6I-1p for pgsql-committers@arkaria.postgresql.org; Sun, 15 Mar 2026 18:05:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w1ppw-005Ikd-0s for pgsql-committers@arkaria.postgresql.org; Sun, 15 Mar 2026 18:05:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w1ppv-005IkV-2v for pgsql-committers@lists.postgresql.org; Sun, 15 Mar 2026 18:05:12 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w1ppu-00000000HAx-2GKb for pgsql-committers@lists.postgresql.org; Sun, 15 Mar 2026 18:05:11 +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 62FI56L32055745; Sun, 15 Mar 2026 14:05:06 -0400 From: Tom Lane To: Peter Eisentraut cc: Melanie Plageman , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Make typeof and typeof_unqual fallback definitions work on C++11 In-reply-to: <2018118.1773591338@sss.pgh.pa.us> References: <2018118.1773591338@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sun, 15 Mar 2026 12:15:38 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2055743.1773597906.1@sss.pgh.pa.us> Date: Sun, 15 Mar 2026 14:05:06 -0400 Message-ID: <2055744.1773597906@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Doesn't appear to have satisfied any of the previously-broken animals > either. It looks like the C compiler is okay but building bitcode > with clang is not okay. We're really going to need separate > definitions for the two cases. After noting that ladybug is one of the failing animals, I was able to reproduce the failure locally on a Fedora 40 installation. This system has $ gcc --version gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) $ g++ --version g++ (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3) $ clang --version clang version 18.1.8 (Fedora 18.1.8-2.fc40) So far as I can tell, this version of clang does not recognize __typeof_unqual__ at all. It will take typeof_unqual, but only with -std=c23 which we are not passing it. So the short answer is that this is not good enough: We test the underscore variant first so that there is a higher chance that clang used for bitcode also supports it, since we don't test that separately. We could get away with not checking clang separately as long as we weren't using any bleeding-edge C features, but this patch is trying to do exactly that. I think we are going to have to explicitly check all three of CC, CXX, CLANG and cope with the case that they're all different on this point. regards, tom lane