1

LLVM 14.0.2 is now available. This release is a bug-fix release and is API and ABI compatible with 14.0.0.

Note that we have adopted a new release schedule for the project , so there will be a new bug-fix release (14.0.x) every 2 weeks. 14.0.5 is the last planned release, but we may do a 14.0.6 release if there are critical issues found in 14.0.5.

Releases sources and binaries can be found on the release page .

Below is the full list of changes since 14.0.1:

0e27d08cdeb3 [RISCV] Fix crash for section alignment with .option norvc
a36801750327 [asan] Always skip first object from dl_iterate_phdr
1f4c7b2a9120 [RISCV] Don’t emit fractional VIDs with negative steps
e19be4195b87 [RISCV] Add another test showing incorrect BUILD_VECTOR lowering
9efcce92b55b [RISCV] Fix lowering of BUILD_VECTORs as VID sequences
21ce6cfd1d93 [RISCV] Add tests showing incorrect BUILD_VECTOR lowering
58d5fbe2c20b [llvm-mt] Add support /notify_update
50c6ba751fa2 [RISCV] Only try LUI+SHADD+ADDI for int materialization if LUI+ADDI+SHADD failed.
dc30b0d3320d [ELF] --emit-relocs: fix missing STT_SECTION when the first input section is synthetic
324127d8da95 [libcxx] Add some missing xlocale wrapper functions for OpenBSD
ebf29ba9f0a3 [LV] Remove stray debug dump added in 0d2efbb8b82c.
0d2efbb8b82c [LV] Always use add to add scalar iv and (startidx + step) for ints.
e7a9fd4f57d6 [LV] Add test case for PR54427.
9a3e81e1f91f [InstCombine] canonicalize select with signbit test
b83c4a2dc0fb [x86] Fix infinite loop inside DAG combiner with lzcnt feature.
0fbe860711be [Clang][Fortify] drop inline decls when redeclared
571c7d8f6dae Reland “[llvm][AArch64] Insert “bti j” after call to setjmp”
0f56ce0fb207 [DebugInfo][InstrRef] Avoid a crash from mixed variable location modes
e8f03f2057ee Force GHashCell to be 8-byte-aligned.
09fba23d41f7 [compiler-rt] Implement __clear_cache on FreeBSD/powerpc
33504b3bbe10 [PowerPC] Allow absolute expressions in relocations
3400d0293a14 [CMake] Update cache file for Win to ARM Linux cross toolchain builders. NFC.
6c41c8edb0cc [CMake] Replace TARGET_TRIPLE with TOOLCHAIN_TARGET_TRIPLE for Win-to-Arm cross toolchain cache file. NFC.
b6dbee34387d [CMake] Update cache file for Win to ARM cross tooolchain. NFC.
46d19f3a8699 [CMake] Use CMAKE_SYSROOT to build libs for Win to ARM cross tooolchain. NFC.
e11b929a3c97 [LLD][COFF] Fix TypeServerSource matcher with more than one collision
d800180f6bee [lld][COFF] Fix TypeServerSource lookup on GUID collisions
8c3445ac1c8b [AArch64][LOH] Don’t ignore regmasks in bundles by iterating over instrs.
43ee392dd462 [InstCombine] try to fold low-mask of ashr to lshr
5ea5e3c01b7b [InstCombine] add tests for low-mask of ashr; NFC
fe8a27acd716 [LV] Handle zero cost loops in selectInterleaveCount.
2c4d288eae8b [RISCV][NFC] Add missing lit.local.cfg in test/CodeGen/MIR/RISCV/
d0f27fb44952 [RISCV] Fixing stack offset for RVV object with vararg in stack.
b6e91d4a331e [RISCV] Pre-commit for fixing stack offset for RVV object
87599bdabbd1 [RISCV] Store/restore RISCVMachineFunctionInfo into MIR YAML file
5c9eed741dbd [libc++] Make __dir_stream visibility declaration consistent

2

Was it intentional that the path for clang includes remains lib/clang/14.0.1/include?

Probably off topic for 14, but the churn in this path is kind of annoying in the FreeBSD base system because we maintain a list of obsolete paths effectively forever. I’m not entirely convinced the release version in the path is useful at all given there isn’t support for installing the rest of the compiler bits multiple times at the same prefix. If we are going to keep it I wonder if we shouldn’t be using just major or major.minor rather than the whole thing,

1 Like
3

Yeah, I think the version hasn’t been updated correctly.

cc @tstellar
I think the 14.0.2 should be removed

4

This has happened before with the release candidates. How big of a problem will this be? I was thinking it was OK to leave it an fix it in 14.0.3 in 2 weeks. I also proposed a CI job to check the version going forward: ⚙ D124539 workflows: Add a test to ensure that the LLVM version is correct

5

I think using the major version only in the path was proposed before, but I can’t find the thread. I think it would be good to start another discussion about this, because it’s also been an issue for us in Fedora.

6

I can either skip 14.0.2 (after all, it’s only two weeks and I don’t currently have users with specific complaints addressed by the release) or work around this issue in the build system.

7

On the Debian/Ubuntu, this cannot be uploaded, it will break too many things.
I will have either patches it to update or wait for 14.0.3

8

After reading over the 14.0.1 version bump commit (bd8dc965cff14115415f18d7dc8922f806f7a93a) I realized that for the FreeBSD port (which doesn’t include runtimes over than sanitizers) all I needed to do was add -DLLVM_VERSION_PATCH=2 to the cmake arguments. Nominally lit will have the wrong version but I don’t think it matters so I’m not going to patch it for a single version.

9

Any preferences about how to resolve this? I was originally thinking it was small enough impact that we could just wait 2 weeks for 14.0.3, but now it sounds like the Windows builds are having problems: We have either do 14.0.3 right away or wait and do it in 2 weeks as scheduled.

Should we do 14.0.3 immediately and drop 14.0.2 from the release page or just wait?

10

My preference would be to release 14.0.3 directly. So the fixes are out faster and we don’t get two weeks of people asking where 14.0.2 went.

1 Like
11

I’m leaning towards doing this too. I’ll plan to do this later today unless someone has a good reason not to.

1 Like