[10.0.0 Release] Release Candidate 5 is here

Hello again,

I had hoped that rc4 would be the last one, but I wanted to pick up
one more fix, so here we go.

Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the
release branch at 35627038123.

Source code and docs are available at
https://prereleases.llvm.org/10.0.0/#rc5 and

If nothing new comes up, I plan to tag 'final' on Monday. Testers, if
you still have cycles, please take this for a quick spin.


I should have included this in the previous mail: the fix was for
and I also picked up the fix for https://llvm.org/PR45162 which seemed low-risk.

we've updated OpenMandriva, and started a mass build. Looks good so far, except we found 1 more bug (not a regression from previous RCs, but newly exposed by a package update introducing code that triggers it).


I don't think this is an extremely serious bug (takes a few not too common constructs to trigger it), but still would be nice to fix given a lot of users will likely run into it (we can't be the only distro that ships libtorrent-rasterbar).



macOS builds are up, sha256:
No new tests failures:

FAIL: LLVM :: Bindings/Go/go.test (25308 of 67060)
FAIL: ThreadSanitizer-x86_64 :: Darwin/norace-objcxx-run-time.mm
(57231 of 67060)
FAIL: libunwind :: signal_frame.pass.cpp (64770 of 67060)


Uploaded Xubuntu/Ubuntu 19.10.

sha256sum clang+llvm-10.0.0-rc5-x86_64-pc-linux-gnu.tar.xz

Only the following fail.

FAIL: libFuzzer :: max-number-of-runs.test (60714 of 69913)
******************** TEST ‘libFuzzer :: max-number-of-runs.test’ FAILED ********************


One new failure for AArch64, binaries uploaded :


Failing Tests (2):
    AddressSanitizer-aarch64-linux-dynamic :: TestCases/Posix/waitid.cpp
    HWAddressSanitizer-aarch64 :: TestCases/global.c

  Expected Passes : 65364
  Expected Failures : 253
  Unsupported Tests : 3382
  Unexpected Failures: 2

FAIL: HWAddressSanitizer-aarch64 :: TestCases/global.c (24326 of 69001)
******************** TEST 'HWAddressSanitizer-aarch64 ::
TestCases/global.c' FAILED ********************

Probably not worth making it a blocker, but we've run into this while rebuilding our "unsupported" repo (which is basically a collection of old junk that may still be used by a few people, but that nobody is committing to maintain anymore):



For 10.0.0-rc5, I used three patches, which are attached.

Main results on amd64-freebsd11:

  Expected Passes : 67940 (rc4: 67939)
  Expected Failures : 265 (rc4: 265)
  Unsupported Tests : 4654 (rc4: 4654)
  Unexpected Passes : 5 (rc4: 5)
  Unexpected Failures: 540 (rc4: 540)
  Individual Timeouts: 18 (rc4: 18)

Test suite results on amd64-freebsd11:

  Expected Passes : 2398
  Unexpected Failures: 3

Main results on i386-freebsd11:

  Expected Passes : 64993 (rc4: 64993)
  Passes With Retry : 0 (rc4: 1)
  Expected Failures : 248 (rc4: 248)
  Unsupported Tests : 3083 (rc4: 3083)
  Unresolved Tests : 1 (rc4: 1)
  Unexpected Passes : 5 (rc4: 5)
  Unexpected Failures: 231 (rc4: 231)
  Individual Timeouts: 11 (rc4: 9)

As usual, the test suite does not build on i386, due to missing SSE and int128 support.

The i386 builds are still running, I will upload the tarballs and post the results later.

SHA256 (clang+llvm-10.0.0-rc5-amd64-unknown-freebsd11.tar.xz) = 4b27b1bda0f451612475cce6460dad6e82858e88604078913ee736f9f9d834f8
SHA256 (clang+llvm-10.0.0-rc5-i386-unknown-freebsd11.tar.xz) = f6a189006588efe69315cc835b1286403d9b4697ec899ef9935e1bbb10098765


fix-clang-1.diff (447 Bytes)

fix-compiler-rt-1.diff (890 Bytes)

fix-test-suite-1.diff (552 Bytes)


I finished testing llvm-10.0.0 RC5 on Power PC 64bit Little Endian Red Hat 7.4 machine and have uploaded the binary from IBM.

There were no regressions. The sha1 file is attached.


Anil Mahmud

clang+llvm-10.0.0-rc5-powerpc64le-linux-rhel-7.4.sha1 (98 Bytes)

I realize it's late but I've just gotten a major bug report. Long story
short, if you happen to have CUDA toolkit 10.2 installed, clang throws
warnings on every compilation (even non-CUDA) which in turns breaks
CMake checks, which in turn means you can't compile pretty much anything
correctly (including LLVM itself).

I've filed a backport request:

I went ahead and updated all Zig's CI to use rc5, and ran into this problem:

/usr/lib/llvm-10/lib/libclangCodeGen.a(BackendUtil.cpp.o): In function
std::default_delete<llvm::raw_pwrite_stream> >)':
undefined reference to `getPollyPluginInfo()'
collect2: error: ld returned 1 exit status

This is on Ubuntu Bionic, using apt.llvm.org. I believe this is
https://bugs.llvm.org/show_bug.cgi?id=44870 /

This is a regression from LLVM 9. My suggestion to fix this is, rather
than cutting rc6, to update apt.llvm.org with new binaries, which have
polly disabled. It seems to me that people who want Polly enabled are
compiling from source anyway.


Hi Hans,

I don’t know if you’ll be planning on RC6, but this bug: https://bugs.llvm.org/show_bug.cgi?id=45271 was just filed as a regression in LLVM 10 versus LLVM 9, and looks like it could break things (potentially silently) for at least some installations of llvm-strip. There’s a fix that’s basically ready (https://reviews.llvm.org/D76562). I’ll leave it up to you as to whether the fix should be included in the release or not (it almost certainly should be in a patch release if it doesn’t, I think).


That sounds reasonable to me. +Sylvestre Ledru do you control these
package configs?

I think it's too late for this, but distributions that install the
tool like that may want to take that patch downstream.

I do but I don't think disabling polly is the right option (and I have seen
people using polly from the package).
Instead, we should fix the issue (maybe only in the Debian/Ubuntu package).



Finally managed to build rc5 for 32bit ARM which still has the issues
already reported (CFI PR44157 and Asan PR44158).

Binaries uploaded:

Final release builds on-going.