[9.0.0 Release] Release Candidate 3 is here

Project Infrastructure Release Testers
#1

Hello everyone,

9.0.0-rc3 was tagged today from the release_90 branch at r370450. In
the Git monorepo, it's tagged as llvmorg-9.0.0-rc3.

Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc3

Binaries will be added as they become available.

There are currently no open release blockers, which means if nothing
new comes up, the final release could ship soon and this is what it
would look like (except for more release notes, which are still very
welcome).

Please file bug reports for any issues you find, and mark them
blocking https://llvm.org/PR42474

Release testers, please run the test script, share your results and
upload binaries.

Many thanks,
Hans

#2

Xubuntu 19.04 - should be the same for Ubuntu 19.04.

sha256sum clang+llvm-9.0.0-rc3-x86_64-pc-linux-gnu.tar.xz
11946901d066cf0c7038b2b14c4c83525e73933d4c85355d98c57b8a8cbd2fb7

Uploaded to the /home/testers directory.

Tail of the run log.
– Testing: 919 tests, 7 threads –
Testing: 0 … 10… 20… 30… 40… 50… 60… 70… 80… 90…
Testing Time: 542.23s
Expected Passes : 919
[100%] Built target check

Packaging the release as clang+llvm-9.0.0-rc3-x86_64-pc-linux-gnu.tar.xz

Testing Finished

Logs: /home/nnelson/Documents/llvm-project/llvm/utils/release/rc3/logs

Errors:

[Release+Asserts Phase3] check-all failed

grep fail *.log
deferred_errors.log:[Release+Asserts Phase3] check-all failed
testing.9.0.0-rc3.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc3.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc3.log:[Release+Asserts Phase3] check-all failed
testing.9.0.0-rc3.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc3.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile

This pair of fails occurred more frequently in my logs from the rc2 run. They have been reduce by using -DRUN_HAVE_GNU_POSIX_REGEX=0 -DRUN_HAVE_THREAD_SAFETY_ATTRIBUTES=0. The other fail not of these two types was removed using -DLLVM_ENABLE_LIBPFM=OFF.

Regards, Neil Nelson

#3

I'm sorry for noticing it this late (I was on vacation) but it seems
that 9.x has some regression that causes the following tests to hang
on NetBSD:

    LLVM :: ExecutionEngine/MCJIT/eh-lg-pic.ll
    LLVM :: ExecutionEngine/MCJIT/eh.ll
    LLVM :: ExecutionEngine/MCJIT/multi-module-eh-a.ll
    LLVM :: ExecutionEngine/OrcMCJIT/eh-lg-pic.ll
    LLVM :: ExecutionEngine/OrcMCJIT/eh.ll
    LLVM :: ExecutionEngine/OrcMCJIT/multi-module-eh-a.ll

I've been able to pinpoint first bad commit as r364550:

  Bitcode: derive all types used from records instead of Values.

However, it seems that trunk works fine. I'm currently searching
for a possible fix, and I will request backporting once I find it.

#4

The Windows binaries were built with the attached script and have the
following checksums:

$ sha256sum *.exe
f43b2b2cce384e66c2cf8daa7a9744c326b398dacb543cdf3c29eb12969840f7
LLVM-9.0.0-rc3-win32.exe
07f6f735523f2f65e79a5355b37c5a33d2f678bf10cfd32569898f4a821d4bed
LLVM-9.0.0-rc3-win64.exe

build_llvm_900-rc3.bat|attachment (5.58 KB)

#5

I've filed [1] for the backport. However, it seems that we need this
linking for reasons other than listed in the commit message.

[1] https://bugs.llvm.org/show_bug.cgi?id=43196

#6

ARM & AArch64 uploaded:
655d6ed6f8038d3203aa446e7dad11f63eeb58625bce6b381e4a5e5cc90e9d4c
clang+llvm-9.0.0-rc3-aarch64-linux-gnu.tar.xz
ee9a69a75616a2d0fe60b04b78fcfdb04cf1668960d15ba064b7557e2ccf80f9
clang+llvm-9.0.0-rc3-armv7a-linux-gnueabihf.tar.xz

No new hiccups.

Cheers,
Diana

#7

Uploaded Ubuntu 14 and SLES11.3 binaries:

3a85c2990498fbd5c06bd5df85aff22ac1e795ee clang+llvm-9.0.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz
ba43ef59b07cdf996be51ac9d0b784af34aa9dc4 clang+llvm-9.0.0-rc3-x86_64-linux-sles11.3.tar.xz

I'll see if I can get access to an ubuntu16 and 18 machines -- the ubuntu machine I usually use for these builds is currently having some problems.

#8

From: Brian Cain
Sent: Tuesday, September 3, 2019 1:12 PM

...

Uploaded Ubuntu 14 and SLES11.3 binaries:

3a85c2990498fbd5c06bd5df85aff22ac1e795ee clang+llvm-9.0.0-rc3-x86_64-
linux-gnu-ubuntu-14.04.tar.xz
ba43ef59b07cdf996be51ac9d0b784af34aa9dc4 clang+llvm-9.0.0-rc3-x86_64-
linux-sles11.3.tar.xz

I'll see if I can get access to an ubuntu16 and 18 machines -- the ubuntu
machine I usually use for these builds is currently having some problems.

I uploaded Ubuntu14 and Ubuntu16 earlier today. I accidentally uploaded SLES11's 9.0 rc2 yesterday when I had claimed to upload ubuntu14.

8f08f94a63ebb0ddebeddd7a9cde1705eaa70fe7 clang+llvm-9.0.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz

#9

From: Brian Cain

...

#10

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.0-rc3-amd64-unknown-freebsd11.tar.xz) = 4b5f1e9c62985fdb397ec66e52a24cef0a20a458cd482f7ae318f6c8aab082b5
SHA256 (clang+llvm-9.0.0-rc3-i386-unknown-freebsd11.tar.xz) = d040218dc6db3a6e5d5e520047582c6b006905221725d9a503697a3b74763f96

Main test results on amd64-freebsd11:

#11

Hello,

Hello everyone,

9.0.0-rc3 was tagged today from the release_90 branch at r370450. In
the Git monorepo, it's tagged as llvmorg-9.0.0-rc3.

I experienced an issue with lto. Initially not clang related but might be.

For a few months, I have been building packages using ThinLTO (
-DLLVM_ENABLE_LTO="Thin" ) and stage2. gcc for stage1.

Debian unstable and the next Ubuntu updated to gcc-9. This version is stricter
on -flto (only accept understood values ([1]).
It caused the build to fail on polly with "No ffs implementation found" (which is just
cmake failing with -flto=thin) [2]
This clearly makes sense.
So, I tried to use -DBOOTSTRAP_LLVM_ENABLE_LTO="Thin" to have only -flto=Thin used in the stage2.

However, this caused two issues:
* Some packages became much bigger (21M => 141M)
* Linking failed for some packages with:
/usr/bin/ld: /usr/lib/llvm-9/lib/libclangCodeGen.a: error adding symbols: archive has no index; run ranlib to
one [3]

I tried to play with clang cmake file [4] but I haven't been able to fix it.

For now, I am forcing the usage of gcc-8 but this won't scale.

Anyway, probably not a blocker for the 9 release but I prefer to report this in case other are getting this issue.

Cheers,
Sylvestre
[1] https://github.com/gcc-mirror/gcc/commit/907e3499443d0e441fcb3b7575d6432598413bff#diff-439a293950478cb6a956c187f26afb48
[2] https://bugs.llvm.org/show_bug.cgi?id=43193
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939472
[4] https://github.com/llvm/llvm-project/blob/release/9.x/clang/CMakeLists.txt#L626

#12

Thanks for raising it.

I've never used our cmake files to bootstrap directly. Does it work if
you do the steps manually: first invoke cmake and do a regular build
with gcc 9, then invoke cmake separately for the second build, setting
the flags to use the clang and lld from the first step, with thinlto?