Skip to content

Llvm 22 upgrades and fixes#3821

Open
rchildre3 wants to merge 4 commits intoAFLplusplus:mainfrom
rchildre3:llvm-22-upgrades-and-fixes
Open

Llvm 22 upgrades and fixes#3821
rchildre3 wants to merge 4 commits intoAFLplusplus:mainfrom
rchildre3:llvm-22-upgrades-and-fixes

Conversation

@rchildre3
Copy link
Copy Markdown
Contributor

Description

Closes #3769

I see the comments from @tokatoka that:

imo all [libafl_cc compiler passes] should go away except cmplog

#3769 (comment)

and:

at this point, i'd say just we should remove everything except for cmplog and autotokens

#3777 (comment)

With concurrence from @domenukk :

I agree we shoudl [sic] remove the defunct ones (or update if an AI can do the job / we still need something)

#3777 (comment)

But as a stopgap here is a PR that gets everything compiling with no deprecation warnings with LLVM 22

Checklist

  • I have run ./scripts/precommit.sh and addressed all comments

rchildre3 added 4 commits May 5, 2026 16:40
`PassPlugin.h` was moved from `Passes/` to `Plugins/` in LLVM commit:

`f54df0d09e19 ([LLVM][NFC] Move PassPlugin from Passes to separate library, 2025-12-22)`

(First tagged in LLVM 22 releases)
LLVM began introducing opaque pointers (pointer types with purposefully
undefined pointee types) around LLVM 13[1] like in commit:

`2155dc51d700 ([IR] Introduce the opaque pointer type, 2021-05-01)`

introducing the function:

`PointerType::get(LLVMContext &C, unsigned AddressSpace)`

and had wholesale switched to only opaque pointers by LLVM 17[2].  Part
of that effort deprecates many functions, including:

`PointerType::get(Type *ElementType, unsigned AddressSpace)`

though this function was depreacted much later in LLVM 21 in
commit:

`146ad71bc71a ([IR] Deprecate PointerType::get/getUnqual pointee type overload (#134517), 2025-04-07)`

Switch libafl_cc's passes to the new function to avoid deprecation
warnings

[1]: https://releases.llvm.org/13.0.1/docs/ReleaseNotes.html#changes-to-the-llvm-ir
[2]: https://releases.llvm.org/22.1.0/docs/OpaquePointers.html#version-support
Constructing an ArrayRef from a nullopt was deprecated in LLVM commit:

`2529de5c935a ([ADT] Deprecate ArrayRef(std::nullopt) (#146011), 2025-06-27)`

(First tagged in LLVM 21)

Then removed in LLVM commit:

`cfbb4cc31215 ([ADT] Remove ArrayRef(std::nullopt_t) (#165831), 2025-10-31)`

(First tagged in LLVM 22)

The LLVM authors recommend switching to the `{}` C++ syntax, so
introduce that conditional as a macro if and only if the LLVM version is
greater than or equal to 21 and fall back to the previous nullopt
workaround
`FATAL` is defined in the `common-llvm.h` and is therefore accessible to
all of the passes, remove the duplicate in the pass `.cc` file to remove
the compiler warning
@rchildre3 rchildre3 force-pushed the llvm-22-upgrades-and-fixes branch from 2405609 to b91ef19 Compare May 5, 2026 21:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

libafl_cc passes are incompatible with LLVM>=22

1 participant