On 07.03.26 01:17, Jelte Fennema-Nio wrote:
On Fri, 6 Mar 2026 at 20:17, Peter Eisentraut <[email protected]> wrote:
This revealed an insufficiency in that commit, which I fix in the first
patch.
Thanks!
There is a failure related to this on buildfarm member sevengill:
../pgsql/src/test/modules/test_cplusplusext/test_cplusplusext.cpp:41:22:
error: no template named 'remove_reference_t' in namespace 'std'; did
you mean 'remove_reference'?
I don't know how that makes sense. Maybe this is a problem in the local
installation of the compiler or standard library.
(This is also a bit suspicious because AFAICT, clang 15 defaults to
C++14, but on that animal it thinks it needs to add -std=gnu++11.)
I have addressed the above problem by swapping the order of the probes
(putting the underscore variant first), as discussed.
Annoying that this is needed, but I agree that it's the least bad
option in this case.
I committed this and it still fails, but the failure is now narrower.
There is a failure on buildfarm member taipan because it uses an unusual
combination of gcc and clang (the gcc is much newer than clang). The
only sensible workaround I could think of is a hardcoded override based
on the clang version, as in the attached patch. And alternative is that
we decide that we don't want to support this combination, meaning that
we would effectively require that clang is approximately as-old-or-newer
than gcc.
From 5295cbb0a4573ea886f21d4f5e89ce7beaf60f58 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
Date: Fri, 13 Mar 2026 11:20:31 +0100
Subject: [PATCH] Hardcode override of typeof_unqual for clang-for-bitcode
The fundamental problem is that when we call clang to generate
bitcode, we might be using configure results from a different
compiler, which might not be fully compatible with the clang we are
using. In practice, clang supports most things other compilers
support, so this has apparently not been a problem in practice.
But commits 4cfce4e62c8, 0af05b5dbb4, and 59292f7aac7 have been
struggling to make typeof_unqual work in this situation. Clang added
support in version 19, GCC in version 14, so if you are using, say,
GCC 14 and Clang 16, the compilation with the latter will fail.
Again, in practice, this might be unlikely, because GCC 14 and Clang
19 were released within a few months of each other, and so Linux
distributions are likely to have suitable combinations. But buildfarm
member "taipan" does not (gcc 15, clang 16), so I'll try to fix it.
The fully correct solution would be to run a separate set of configure
tests for that clang-for-bitcode, but that would be very difficult to
implement, and probably of limited use in practice. So the workaround
here is that we hardcodedly override the configure result under clang
based on the version number. As long as we only have a few of these
cases, this should be manageable.
Discussion:
https://www.postgresql.org/message-id/flat/92f9750f-c7f6-42d8-9a4a-85a3cbe808f3%40eisentraut.org
---
src/include/c.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/src/include/c.h b/src/include/c.h
index 2aab74d8b0e..2e789b00594 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ -432,6 +432,21 @@ extern "C++"
#define unlikely(x) ((x) != 0)
#endif
+/*
+ * When we call clang to generate bitcode, we might be using configure results
+ * from a different compiler, which might not be fully compatible with the
+ * clang we are using. The fully correct solution would be to run a separate
+ * set of configure tests for that clang-for-bitcode, but that could be very
+ * difficult to implement, and in practice clang supports most things other
+ * compilers support. So this section just contains some hardcoded ugliness
+ * to override some configure results where it is necessary.
+ */
+#if defined(__clang__)
+#if __clang_major__ < 19
+#undef HAVE_TYPEOF_UNQUAL
+#endif
+#endif /* __clang__ */
+
/*
* Provide typeof in C++ for C++ compilers that don't support typeof natively.
* It might be spelled __typeof__ instead of typeof, in which case
--
2.53.0
