Subject: pgsql: Track LLVM 15 changes.

From: Thomas Munro <[email-masked]>
Date: Mon, 14 Feb 2022 02:56:47 +0000

Track LLVM 15 changes.

This isn't an API change, it's just a missing #include that we got away
with before.  Per buildfarm animal seawasp.

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/0052fb489008a68d0f3e0445f52e1ab3166632a4

Modified Files
--------------
src/backend/jit/llvm/llvmjit_inline.cpp | 1 +
1 file changed, 1 insertion(+)

---

From: Fabien COELHO <[email-masked]>
Date: Mon, 14 Feb 2022 16:06:10 +0100 (CET)

Hello Thomas,

> with before.  Per buildfarm animal seawasp.

If it is a somehow *missing* include, should it be back-patched? Not sure, 
just asking.

-- 
Fabien.

---

From: Thomas Munro <[email-masked]>
Date: Tue, 15 Feb 2022 09:59:32 +1300

> If it is a somehow *missing* include, should it be back-patched? Not sure,

Arguably (I think it'd work fine on ancient LLVM as far back as we
currently support, based on the age of that header[1]), but since
there's no actual problem with older LLVM releases, I figured we
should let sleeping dogs lie.

My general plan for this stuff is to try to do just one back-patch for
each LLVM release, with all the changes in it, to reduce commit churn.
Hence commit messages that say "Track LLVM X ..." so that it's easy to
find all the changes for X around the time of X's release.  In other
words I'll probably do the 14 back-patch next month, so our May
releases will compile and work against LLVM 14, due out in March.
Then I'll scoop up the accumulated 15 stuff around October or whatever
it turns out to be.  (With 13 I "pre-empted" their release with commit
9b4e4cfe, because we could still compile OK against 13 but we would
crash on some queries, so it seemed worth the extra effort to avoid
having that situation in the field, but I'm not sure if releasing
"before" them is really sustainable; I'd have had to get the 14
changes into our recent release, before their RC1.)  Open to better
ideas about how we should manage this stuff.

[1] https://github.com/llvm/llvm-project/blob/llvmorg-3.9.0/llvm/include/llvm/Support/MemoryBuffer.h

---

From: Alvaro Herrera <[email-masked]>
Date: Mon, 14 Feb 2022 18:22:33 -0300

> releases will compile and work against LLVM 14, due out in March.

In this case, maybe you should get this task listed in RELEASE_CHANGES.

-- 
Álvaro Herrera

---

From: Thomas Munro <[email-masked]>
Date: Tue, 15 Feb 2022 11:15:24 +1300

> In this case, maybe you should get this task listed in RELEASE_CHANGES.

This really depends on *their* release cycle, not ours.  Hmm.  Well,
if we had a buildfarm animal that ran their latest release branch as
recently discussed, not their main branch, then we could say "if that
machine is failing, but seawasp is passing, now is the time to
back-patch all the 'Track LLVM X' patches; if seawasp is failing, we
should urgently look into why".  I'm willing to set such an animal up,
but Fabien or Andres may want to... A bit of shell scripting to peek
at their branches or look for their RC1 tag or something like that
depending on what we decide is the right trigger point.

---

From: Tom Lane <[email-masked]>
Date: Tue, 15 Feb 2022 13:34:29 -0500

> depending on what we decide is the right trigger point.

Although seawasp isn't actually failing at the moment, it's emitting
a boatload of deprecation warnings, eg

In file included from llvmjit_deform.c:27:
../../../../src/include/jit/llvmjit_emit.h:112:23: warning: 'LLVMBuildStructGEP' is deprecated: Use LLVMBuildStructGEP2 instead to support opaque pointers [-Wdeprecated-declarations]
        LLVMValueRef v_ptr = LLVMBuildStructGEP(b, v, idx, "");
                             ^
/home/fabien/clgtk/include/llvm-c/Core.h:3908:1: note: 'LLVMBuildStructGEP' has been explicitly marked deprecated here
LLVM_ATTRIBUTE_C_DEPRECATED(
^

Is that on anyone's radar to clean up?

			regards, tom lane

---

From: Thomas Munro <[email-masked]>
Date: Wed, 16 Feb 2022 09:18:53 +1300

> Is that on anyone's radar to clean up?

Yeah I mentioned this problem in the other thread.  I got as far as
finding this write-up:

https://llvm.org/docs/OpaquePointers.html

I haven't yet tried to work out what we really need to do, but I'm
planning to try.  Possibly requires a bit more book keeping on our
part, since eg LLVMGetElementType() is going away.

---

From: Andres Freund <[email-masked]>
Date: Tue, 15 Feb 2022 14:41:23 -0800

Hi,

> https://llvm.org/docs/OpaquePointers.html

Given that major parts of llvm (clang alone contains ~1k references) aren't
yet transitioned, I wonder if should silence them for now?

> part, since eg LLVMGetElementType() is going away.

I can't yet really tell whether it'll be simpler because pointer types aren't
a thing anymore, or harder because the llvmjit_types.c mechanism won't work
well anymore.

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Tue, 15 Feb 2022 17:44:40 -0500

> yet transitioned, I wonder if should silence them for now?

For my own part, I don't have any problem with just filtering these
warnings for now.  I don't need any buildfarm changes for that.

			regards, tom lane

---

From: Thomas Munro <[email-masked]>
Date: Tue, 15 Mar 2022 12:12:44 +1300

> warnings for now.  I don't need any buildfarm changes for that.

Shortly I'll do the back-patch of LLVM 14 API changes (their final
release tag is scheduled for tomorrow, as I've been reminded by
package maintainers trying and failing to build).  But I figured I
should also follow up on this bandaid solution to the API deprecation
warnings, that is, silencing them for now, so we don't spew screeds of
warnings.  Does someone have a better idea than the attached?
From 91d1f833cbf6f19b5ebb4ec59a44d122725a5963 Mon Sep 17 00:00:00 2001
From: Thomas Munro <[email-masked]>
Date: Tue, 15 Mar 2022 12:01:49 +1300
Subject: [PATCH] Silence LLVM 14 API deprecation warnings.

We are going to need to handle the opaque pointer API changes[1],
possibly in time for LLVM 15, but in the meantime let's silence the
warnings produced by LLVM 14.

[1] https://llvm.org/docs/OpaquePointers.html

Discussion: https://postgr.es/m/CA%2BhUKG%2Bp%3DfaBQR2PSAqWoWa%2B_tJdKPT0wjZPQe7XcDEttUCgdQ%40mail.gmail.com
---
 src/backend/jit/llvm/Makefile | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/src/backend/jit/llvm/Makefile b/src/backend/jit/llvm/Makefile
index 0268bd46d5..4af57b02b0 100644
--- a/src/backend/jit/llvm/Makefile
+++ b/src/backend/jit/llvm/Makefile
@@ -22,6 +22,12 @@ endif
 PGFILEDESC = "llvmjit - JIT using LLVM"
 NAME = llvmjit
 
+# LLVM 14 produces deprecation warnings.  We'll handle those, but for now
+# silence the warnings.
+ifeq ($(GCC), yes)
+LLVM_CFLAGS += -Wno-deprecated-declarations
+endif
+
 # All files in this directory use LLVM.
 CFLAGS += $(LLVM_CFLAGS)
 CXXFLAGS += $(LLVM_CXXFLAGS)
-- 
2.30.2

---

From: Andres Freund <[email-masked]>
Date: Tue, 15 Mar 2022 11:28:58 -0700

Hi,

On 2022-03-15 12:12:44 +1300, Thomas Munro wrote:
> package maintainers trying and failing to build).

+1

> But I figured I

Hm. No, no I don't see something better. There's ugly stuff like redefining
LLVM_ATTRIBUTE_DEPRECATED but that seems worse.

Greetings,

Andres Freund

---

From: Thomas Munro <[email-masked]>
Date: Sun, 17 Apr 2022 15:50:19 +1200

> part, since eg LLVMGetElementType() is going away.

And now seaswap fails with an assertion about that.  I'll try to have
a look this week.  Just to be clear, this is an LLVM 15-to-be problem
so we have some time.

#3  0x00007f5eea78e006 in __GI___assert_fail (assertion=0x7f5edce1d730
"NumContainedTys && \\"Attempting to get element type of opaque
pointer\\"", file=0x7f5edce1d668
"/home/fabien/llvm-src/llvm/include/llvm/IR/Type.h", line=380,
function=0x7f5edce1d6d0 "llvm::Type*
llvm::Type::getNonOpaquePointerElementType() const") at assert.c:101
#4  0x00007f5edca8deae in llvm::Type::getNonOpaquePointerElementType
(this=0x561441f6eb40) at
/home/fabien/llvm-src/llvm/include/llvm/IR/Type.h:380
#5  0x00007f5edcb6e54f in LLVMGetElementType
(WrappedTy=0x561441f6eb40) at
/home/fabien/llvm-src/llvm/lib/IR/Core.cpp:801
#6  0x00007f5edf85ffe0 in llvm_pg_var_type () from
/home/fabien/pg/build-farm-14/buildroot/HEAD/pgsql.build/tmp_install/home/fabien/pg/build-farm-14/buildroot/HEAD/inst/lib/postgresql/llvmjit.so
#7  0x00007f5edf85f102 in llvm_create_context () from
/home/fabien/pg/build-farm-14/buildroot/HEAD/pgsql.build/tmp_install/home/fabien/pg/build-farm-14/buildroot/HEAD/inst/lib/postgresql/llvmjit.so
#8  0x00007f5edf86a3c9 in llvm_compile_expr () from
/home/fabien/pg/build-farm-14/buildroot/HEAD/pgsql.build/tmp_install/home/fabien/pg/build-farm-14/buildroot/HEAD/inst/lib/postgresql/llvmjit.so
#9  0x00005614404c24d4 in ExecBuildProjectionInfo ()
#10 0x00005614404deb92 in ExecAssignProjectionInfo ()
#11 0x0000561440505724 in ExecInitNestLoop ()
#12 0x00005614404d7851 in ExecInitNode ()
#13 0x0000561440508064 in ExecInitSort ()
#14 0x00005614404d78ab in ExecInitNode ()
#15 0x00005614404cfe92 in standard_ExecutorStart ()
#16 0x0000561440687846 in PortalStart ()
#17 0x0000561440686cbc in exec_simple_query ()
#18 0x000056144068491d in PostgresMain ()
#19 0x00005614405e24bb in BackendRun ()
#20 0x00005614405e1d1a in ServerLoop ()
#21 0x00005614405df217 in PostmasterMain ()
#22 0x000056144052dc0c in main ()

---

From: Tom Lane <[email-masked]>
Date: Thu, 25 Dec 2025 12:05:19 -0500

[ blast-from-the-past dept. ]

> warnings.  Does someone have a better idea than the attached?

The bit added by commit a56e7b660 is still there in
src/backend/jit/llvm/Makefile:

+# LLVM 14 produces deprecation warnings.  We'll need to make some changes
+# before the relevant functions are removed, but for now silence the warnings.
+ifeq ($(GCC), yes)
+LLVM_CFLAGS += -Wno-deprecated-declarations
+endif

Surely we don't need this anymore?  I tried removing it locally
and didn't see any such warnings (with Red Hat's llvm 20.1.8).

			regards, tom lane

---

From: Thomas Munro <[email-masked]>
Date: Mon, 29 Dec 2025 22:15:57 +1300

> and didn't see any such warnings (with Red Hat's llvm 20.1.8).

Yeah.  We should just delete these obsolete lines in 18 and master.
For older branches, I think it should be enough to update the comment
in 14-17, as attached.  We could work harder and suppress the warnings
only for LLVM 14 and 15 specifically in PostgreSQL 14-17, but it seems
like the main point is surely to have *something* watching out for new
warnings that are added in future LLVM versions, and we'll get that
from the newer branches.

---

From: Tom Lane <[email-masked]>
Date: Mon, 29 Dec 2025 10:12:37 -0500

> in 14-17, as attached.

LGTM.

> We could work harder and suppress the warnings

Agreed, not worth the trouble.

			regards, tom lane