On Tue Mar 17, 2026 at 3:39 AM CET, Tom Lane wrote:
While this version of clang doesn't like typeof_unqual, it does take __typeof_unqual__. So maybe we were premature to decide that we could prefer the typeof_unqual spelling.
Hmmm, that makes sense. How about this patch to at least keep the all the logic related to this in one place? I was able to reproduce this error using the following flags, and this fixes the issue for me. CC=clang-21 CXX=clang++-21 CFLAGS=-std=c23 BITCODE_CFLAGS=-std=gnu17 CLANG=clang-19 LLVM_CONFIG=llvm-config-19
From b0261abce45ff144bc6f8c9d797984f8377fcfe0 Mon Sep 17 00:00:00 2001 From: Jelte Fennema-Nio <[email protected]> Date: Tue, 17 Mar 2026 11:34:16 +0100 Subject: [PATCH v1] Hardcode typeof_unqual to __typeof_unqual__ for clang A new attempt was made in 63275ce84d2 to make typeof_unqual work on all configurations of CC and CLANG. This re-introduced an old problem though, where CLANG would only support __typeof_unqual__ but the configure check for CC detected support for typeof_unqual. This fixes that by always defining typeof_unqual as __typeof_unqual__ under clang. --- src/include/c.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/include/c.h b/src/include/c.h index 8987a121d6a..fd6b093bb3a 100644 --- a/src/include/c.h +++ b/src/include/c.h @@ -444,6 +444,9 @@ extern "C++" #if defined(__clang__) #if __clang_major__ < 19 #undef HAVE_TYPEOF_UNQUAL +#else +#undef typeof_unqual +#define typeof_unqual __typeof_unqual__ #endif #endif /* __clang__ */ base-commit: 182cdf5aeaf7b34a288a135d66f2893dc288a24e -- 2.53.0
