LLVM 14.0.1 Release

Announcements
1

LLVM 14.0.1 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.0:

c62053979489 [AArch64] Fix the upper limit for folded address offsets for COFF
6697c5bc3a1e [compiler-rt] [scudo] Use -mcrc32 on x86 when available
8475349bd639 [AARCH64] ssbs should be enabled by default for cortex-x1, cortex-x1c, cortex-a77
d4e3c50b2bda [libc++] Define namespace views in its own detail header.
ec13fed5867f [X86] lowerV8I16Shuffle - use explicit SmallVector<SDValue, 4> width to avoid MSVC AVX alignment bug
aaf0c921a54a [clang-repl] Add an accessor to our underlying execution engine
d150523f0776 [AArch64] Use correct calling convention for each vararg
fd98b0f1a6a1 [SelectionDAG] Don’t create illegally-typed nodes while constant folding
d53e2603383a [AArch64] Allow .variant_pcs before the symbol is registered
67a290460c37 [VectorCombine] Insert addrspacecast when crossing address space boundaries
353068233f21 [ELF] Fix llvm_unreachable failure when COMMON is placed in SHT_PROGBITS output section
311a622edd31 [Object][test] Fix invalid.test
1007cb795a3c [llvm-objdump] --private-headers: change errors to warnings for dynamic section dumping
c9ec4902c3e3 [llvm-objdump][test] dos2unix some files
5b9dd016bec7 [SelectionDAG][RISCV] Make RegsForValue::getCopyToRegs explicitly zero_extend constants.
e9b26b5b2a70 [RISCV] Add test case for miscompile caused by treating ANY_EXTEND of constants as SIGN_EXTEND.
a4681df0202c [libcxx] [test] Avoid spurious test breakage in clang-cl-dll configs with newer CMake
db07d9f098b3 [MC] Fix llvm_unreachable when a STB_GNU_UNIQUE symbol needs a relocation
22d7bee01a5a [PPCISelLowering] Avoid emitting calls to __multi3, __muloti4
23d08271a4b2 Add cmake/ to release tarballs via concatenation
b69247dcbd80 [libcxx] random_device, specify optimal entropy properties for all OS’s using arc4random()
63e7af77ec42 [Clang][NeonEmitter] emit ret decl first for -Wdeclaration-after-statement
f3b89727716a [Driver][OpenBSD] Disable unwind tables on Arm
fe5c24e93754 [docs] Fix typo in tutorial
99c0f85ef992 Re-commit: Driver: Don’t warn on -mbranch-protection when linking
0547ffef5d39 workflows: Consolidate tests to reduce the number of build jobs
bd8dc965cff1 Bump version to 14.0.1
3f43d803382d [libc++] Re-enable workaround for pre-ranges CTAD in std::span
add3ab7f4c8a [libc++] Add workaround to avoid breaking users of when are disabled

4 Likes
LLVM Weekly - #433, April 18th 2022
2

Thanks for your work Tom!

3

While it’s good not to have to wait for releases so long (13.0.1 took many months), two weeks seem pretty short to me.

For the most part these updates should run fine, but sadly Clang’s builtin headers live in a path using the full version i.e. <libdir>/clang/14.0.0/include. Some tools using libclang.so hardcode that (at least qdoc and QtCreator, possibly others as well).

With such a fast release cadence could we reconsider this? My GCC 11 lives with <libdir>/gcc/<triple>/11/include just fine, and if we did the same we could really just plug in a new library and everyone is happy.

4

I am not sure it’s good that these parts are hard coded. Can we expose the version of path via a api from libclang if we don’t do that already instead.

5

We have such an API, but not every tool uses that yet. For what it’s worth, I’d also have to look it up.

But yeah, we’ll probably have to patch these tools anyway.

6

I guess we could supply a symlink in lib/clang where 14 points to the current release. But that probably requires patching the distro packages?

7

Hmm, another issue is that we’re not increasing the sover of libclang.so anymore. So a tool that links against libclang.so.13 might have to go for the builtin headers of Clang 14, so across major versions basically.

By the way, the API call is clang_getClangVersion.

8

Oh well. That function doesn’t just return the version, but something like clang version <version>[-<suffix> (<branch>)], so applications have to parse that. And the documentation warns against that:

/**
 * Return a version string, suitable for showing to a user, but not
 *        intended to be parsed (the format is not guaranteed to be stable).
 */
CINDEX_LINKAGE CXString clang_getClangVersion(void);
9

The canonical way to get the Clang resource directory is clang --print-resource-dir. The path is an internal detail which isn’t supposed to be hard coded by external tools. And llvm-project cannot provide compatibility guarantee.

The name libclang.so is guaranteed. The version in libclang.so.$version is not. A user should trace the symlink to know the version, instead of assuming the current llvm-project major release.

10

That’s good to know, but the clang binary might not be available. I think we should expose the resource directory via some libclang.so function call as well.

Indeed, even if we use the major version only to name the resource directory, a tool that was build against LLVM 13 would stop working with LLVM 14. That’s what I meant.

11

Oh, and also there is no guarantee that the clang command is of the same version as libclang.so. Many distributions allow the installation of multiple compiler versions in parallel, at openSUSE we even leave it up to the user which one is the canonical clang. (Defaulting to the newest version of course.)

But assume an older application built against libclang.so.12 asks clang -> clang-14 what the resource directory is. Well, that might not work out. And as we just determined, the application cannot use the soversion to find the right Clang: clang-13 might already be gone.

12

In case you’re wondering about that: we split up the resources. The package with libclang-cpp.so.X gets the builtin headers, because there is little use of that without those. (They’re not coincidentally required by tools that otherwise only need the library, e.g. include-what-you-use.) The package containing libclang.so.X requires the first package simply because we link libclang against libclang-cpp. Then the package with clang contains the remainder of the resources. (Essentially compiler-rt.) They’re typically required for full compilation only and not pure frontend work, so they don’t really make sense with the libraries.

13

We have run into this same problem in Fedora too. We do create a symlink to from <libdir>/clang/14/ to <libdir>/clang/14.0.0 but I don’t think any of the projects are using this.

I’m in favor of this, but I’ve proposed this in the past and I think there was some valid reasons not to, I just don’t recall what they are.