LLVM 18

Started by Thomas Munroabout 2 years ago4 messages
#1Thomas Munro
thomas.munro@gmail.com
1 attachment(s)

Attachments:

0001-Track-LLVM-18-changes.patchtext/x-patch; charset=US-ASCII; name=0001-Track-LLVM-18-changes.patchDownload
From bc2a07e0012aa58af2cf97a202d181f473a4d7bc Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Wed, 3 Jan 2024 17:45:30 +1300
Subject: [PATCH] Track LLVM 18 changes.

https://github.com/llvm/llvm-project/commit/1b97645e56bf321b06d1353024339958b64fd242
https://github.com/llvm/llvm-project/commit/5ac12951b4e9bbfcc5791282d0961ec2b65575e9

diff --git a/src/backend/jit/llvm/llvmjit_inline.cpp b/src/backend/jit/llvm/llvmjit_inline.cpp
index d92d7f3c88..17c0aa427a 100644
--- a/src/backend/jit/llvm/llvmjit_inline.cpp
+++ b/src/backend/jit/llvm/llvmjit_inline.cpp
@@ -821,7 +821,10 @@ static void
 add_module_to_inline_search_path(InlineSearchPath& searchpath, llvm::StringRef modpath)
 {
 	/* only extension in libdir are candidates for inlining for now */
-	if (!modpath.startswith("$libdir/"))
+#if LLVM_VERSION_MAJOR < 16
+#define starts_with startswith
+#endif
+	if (!modpath.starts_with("$libdir/"))
 		return;
 
 	/* if there's no match, attempt to load */
-- 
2.39.2

#2Thomas Munro
thomas.munro@gmail.com
In reply to: Thomas Munro (#1)
Re: LLVM 18

On Wed, Jan 3, 2024 at 6:04 PM Thomas Munro <thomas.munro@gmail.com> wrote:

LLVM 16 provided a new function name[1], and LLVM 18 (not shipped yet)
has started complaining[2] about the old spelling.

Here's a patch.

And pushed.

Just in case anyone else is confused by this, be aware that they've
changed their numbering scheme. The 18.1 schedule visible on llvm.org
doesn't imply that 18.0 has already shipped, it's just that they've
decided to start at X.1.

By the way, while testing on my Debian system with apt.llvm.org
packages, I discovered that we crash with its latest llvm-18 package,
namely:

llvm-18_1%3a18~++20240122112312+ad01447d30ed-1~exp1~20240122112329.478_amd64.deb

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f033e73f5f8 in llvm::InlineFunction(llvm::CallBase&,
llvm::InlineFunctionInfo&, bool, llvm::AAResults*, bool,
llvm::Function*) () from /lib/x86_64-linux-gnu/libLLVM-18.so.1

... so I re-confirmed that I wasn't hallucinating and it did work
before I disappeared for the holidays by downgrading to the one before
that from my /var/cache/apt/archives, namely:

llvm-18_1%3a18~++20231218112348+a4deb14e353c-1~exp1~20231218112405.407_amd64.deb

So I built the tip of their release/18.x branch so I could try to get
some more information out of my debugger and perhaps their assertions,
but it worked. So I have to assume that something was broken at their
commit ad01447d30ed and has been fixed in the past few days, but I
didn't have time to dig further, and will re-check a bit later when a
fresh package shows up.

#3Christoph Berg
myon@debian.org
In reply to: Thomas Munro (#2)
Re: LLVM 18

Re: Thomas Munro

By the way, while testing on my Debian system with apt.llvm.org
packages, I discovered that we crash with its latest llvm-18 package,
namely:

Ubuntu in their infinite wisdom have switched to LLVM 18 as default
for their upcoming 24.04 "noble" LTS release while Debian is still
defaulting to 16. I'm now seeing LLVM crashes on the 4 architectures
we support on noble.

Should LLVM 18 be supported by now?

Christoph

#4Thomas Munro
thomas.munro@gmail.com
In reply to: Christoph Berg (#3)
Re: LLVM 18

On Sat, Mar 30, 2024 at 7:07 AM Christoph Berg <myon@debian.org> wrote:

Ubuntu in their infinite wisdom have switched to LLVM 18 as default
for their upcoming 24.04 "noble" LTS release while Debian is still
defaulting to 16. I'm now seeing LLVM crashes on the 4 architectures
we support on noble.

Should LLVM 18 be supported by now?

Hi Christoph,

Seems there is a bug somewhere, probably (?) not in our code, but
perhaps we should be looking for a workaround... here's the thread:

/messages/by-id/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch+w98OxYg@mail.gmail.com