public inbox for [email protected]
help / color / mirror / Atom feedpgsql: Track LLVM 15 changes.
15+ messages / 6 participants
[nested] [flat]
* pgsql: Track LLVM 15 changes.
@ 2022-02-14 02:56 Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Munro @ 2022-02-14 02:56 UTC (permalink / raw)
To: [email protected]
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(+)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2022-02-14 15:06 ` Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Fabien COELHO @ 2022-02-14 15:06 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: [email protected]
Hello Thomas,
> This isn't an API change, it's just a missing #include that we got away
> with before. Per buildfarm animal seawasp.
If it is a somehow *missing* include, should it be back-patched? Not sure,
just asking.
--
Fabien.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
@ 2022-02-14 20:59 ` Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Munro @ 2022-02-14 20:59 UTC (permalink / raw)
To: Fabien COELHO <[email protected]>; +Cc: Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
On Tue, Feb 15, 2022 at 4:06 AM Fabien COELHO <[email protected]> wrote:
> > This isn't an API change, it's just a missing #include that we got away
> > with before. Per buildfarm animal seawasp.
>
> If it is a somehow *missing* include, should it be back-patched? Not sure,
> just asking.
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2022-02-14 21:22 ` Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Alvaro Herrera @ 2022-02-14 21:22 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
On 2022-Feb-15, Thomas Munro wrote:
> 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.
In this case, maybe you should get this task listed in RELEASE_CHANGES.
--
Álvaro Herrera
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
@ 2022-02-14 22:15 ` Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Munro @ 2022-02-14 22:15 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
On Tue, Feb 15, 2022 at 10:22 AM Alvaro Herrera <[email protected]> wrote:
> On 2022-Feb-15, Thomas Munro wrote:
> > 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.
>
> 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.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2022-02-15 18:34 ` Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-02-15 18:34 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
Thomas Munro <[email protected]> writes:
> 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.
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
@ 2022-02-15 20:18 ` Thomas Munro <[email protected]>
2022-02-15 22:41 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
2022-04-17 03:50 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Thomas Munro @ 2022-02-15 20:18 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
On Wed, Feb 16, 2022 at 7:34 AM Tom Lane <[email protected]> wrote:
> 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?
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.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2022-02-15 22:41 ` Andres Freund <[email protected]>
2022-02-15 22:44 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Andres Freund @ 2022-02-15 22:41 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
Hi,
On 2022-02-16 09:18:53 +1300, Thomas Munro wrote:
> Yeah I mentioned this problem in the other thread. I got as far as
> finding this write-up:
>
> 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?
> 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.
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 22:41 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
@ 2022-02-15 22:44 ` Tom Lane <[email protected]>
2022-03-14 23:12 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Tom Lane @ 2022-02-15 22:44 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Thomas Munro <[email protected]>; Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
Andres Freund <[email protected]> writes:
> On 2022-02-16 09:18:53 +1300, Thomas Munro wrote:
>> Yeah I mentioned this problem in the other thread. I got as far as
>> finding this write-up:
>> 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?
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 22:41 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
2022-02-15 22:44 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
@ 2022-03-14 23:12 ` Thomas Munro <[email protected]>
2022-03-15 18:28 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
2025-12-25 17:05 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Thomas Munro @ 2022-03-14 23:12 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
On Wed, Feb 16, 2022 at 11:44 AM Tom Lane <[email protected]> wrote:
> Andres Freund <[email protected]> writes:
> > On 2022-02-16 09:18:53 +1300, Thomas Munro wrote:
> >> Yeah I mentioned this problem in the other thread. I got as far as
> >> finding this write-up:
> >> 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?
>
> 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.
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?
Attachments:
[text/x-patch] 0001-Silence-LLVM-14-API-deprecation-warnings.patch (1.1K, 2-0001-Silence-LLVM-14-API-deprecation-warnings.patch)
download | inline diff:
From 91d1f833cbf6f19b5ebb4ec59a44d122725a5963 Mon Sep 17 00:00:00 2001
From: Thomas Munro <[email protected]>
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 22:41 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
2022-02-15 22:44 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-03-14 23:12 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2022-03-15 18:28 ` Andres Freund <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Andres Freund @ 2022-03-15 18:28 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
Hi,
On 2022-03-15 12:12:44 +1300, Thomas Munro wrote:
> 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).
+1
> 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?
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 22:41 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
2022-02-15 22:44 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-03-14 23:12 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2025-12-25 17:05 ` Tom Lane <[email protected]>
2025-12-29 09:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Tom Lane @ 2025-12-25 17:05 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Andres Freund <[email protected]>; Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
[ blast-from-the-past dept. ]
Thomas Munro <[email protected]> writes:
> 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?
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
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 22:41 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
2022-02-15 22:44 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-03-14 23:12 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2025-12-25 17:05 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
@ 2025-12-29 09:15 ` Thomas Munro <[email protected]>
2025-12-29 15:12 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Munro @ 2025-12-29 09:15 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
On Fri, Dec 26, 2025 at 6:05 AM Tom Lane <[email protected]> wrote:
> Thomas Munro <[email protected]> writes:
> > 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?
>
> 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).
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.
Attachments:
[application/octet-stream] 0001-jit-Remove-suppression-of-deprecation-warnings.patch (1.8K, 2-0001-jit-Remove-suppression-of-deprecation-warnings.patch)
download | inline diff:
From 7b60f8f385ecdda80a82d6a99df0db4de2b689a3 Mon Sep 17 00:00:00 2001
From: Thomas Munro <[email protected]>
Date: Mon, 29 Dec 2025 18:13:57 +1300
Subject: [PATCH] jit: Remove suppression of deprecation warnings.
REL_18_STABLE and master have commit ee485912, so they always use the
new opaque pointer API. Revert commit a56e7b660 in those branches, so
that we look out for any new deprecation warnings that arrive in future
LLVM versions.
Older branches continued to use functions marked deprecated in LLVM 14
and 15 (but not LLVM 16+), as a precaution against unforeseen
compatibility problems with bitcode already shipped. In those branches,
the comment explaining the warning suppression is updated to explain
that. In theory those branches could apply the warning suppression only
for LLVM 14 and 15 specifically, but that isn't done here.
Backpatch-through: 14
Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/1407185.1766682319%40sss.pgh.pa.us
---
src/backend/jit/llvm/Makefile | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/backend/jit/llvm/Makefile b/src/backend/jit/llvm/Makefile
index 68677ba42e1..1af95582ea3 100644
--- a/src/backend/jit/llvm/Makefile
+++ b/src/backend/jit/llvm/Makefile
@@ -22,8 +22,10 @@ endif
PGFILEDESC = "llvmjit - JIT using LLVM"
NAME = llvmjit
-# LLVM 14 produces deprecation warnings. We'll need to make some changes
-# before the relevant functions are removed, but for now silence the warnings.
+# Some functions called in LLVM 14 and LLVM 15 are marked with GCC deprecation
+# attributes. For LLVM 16 and later, we use the newer replacement functions
+# instead, but warnings are suppressed unconditionally. (Note that this is
+# only done in branches before REL_18_STABLE.)
ifeq ($(GCC), yes)
LLVM_CFLAGS += -Wno-deprecated-declarations
endif
--
2.52.0
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 22:41 ` Re: pgsql: Track LLVM 15 changes. Andres Freund <[email protected]>
2022-02-15 22:44 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-03-14 23:12 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2025-12-25 17:05 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2025-12-29 09:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2025-12-29 15:12 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Tom Lane @ 2025-12-29 15:12 UTC (permalink / raw)
To: Thomas Munro <[email protected]>; +Cc: Andres Freund <[email protected]>; Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
Thomas Munro <[email protected]> writes:
> On Fri, Dec 26, 2025 at 6:05 AM Tom Lane <[email protected]> wrote:
>> 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).
> 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.
LGTM.
> 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.
Agreed, not worth the trouble.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: pgsql: Track LLVM 15 changes.
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Re: pgsql: Track LLVM 15 changes. Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 21:22 ` Re: pgsql: Track LLVM 15 changes. Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-15 18:34 ` Re: pgsql: Track LLVM 15 changes. Tom Lane <[email protected]>
2022-02-15 20:18 ` Re: pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
@ 2022-04-17 03:50 ` Thomas Munro <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Thomas Munro @ 2022-04-17 03:50 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Fabien COELHO <[email protected]>; Thomas Munro <[email protected]>; pgsql-committers <[email protected]>
On Wed, Feb 16, 2022 at 9:18 AM Thomas Munro <[email protected]> wrote:
> On Wed, Feb 16, 2022 at 7:34 AM Tom Lane <[email protected]> wrote:
> > 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?
>
> 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.
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 ()
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2025-12-29 15:12 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-02-14 02:56 pgsql: Track LLVM 15 changes. Thomas Munro <[email protected]>
2022-02-14 15:06 ` Fabien COELHO <[email protected]>
2022-02-14 20:59 ` Thomas Munro <[email protected]>
2022-02-14 21:22 ` Alvaro Herrera <[email protected]>
2022-02-14 22:15 ` Thomas Munro <[email protected]>
2022-02-15 18:34 ` Tom Lane <[email protected]>
2022-02-15 20:18 ` Thomas Munro <[email protected]>
2022-02-15 22:41 ` Andres Freund <[email protected]>
2022-02-15 22:44 ` Tom Lane <[email protected]>
2022-03-14 23:12 ` Thomas Munro <[email protected]>
2022-03-15 18:28 ` Andres Freund <[email protected]>
2025-12-25 17:05 ` Tom Lane <[email protected]>
2025-12-29 09:15 ` Thomas Munro <[email protected]>
2025-12-29 15:12 ` Tom Lane <[email protected]>
2022-04-17 03:50 ` Thomas Munro <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox