[3.9 Release] Release Candidate 1 has been tagged

Dear testers,

3.9.0-rc1 was just tagged from the 3.9 branch at r277207.

This took a little longer than I'd hoped, but I think the branch is in
a decent state now.

There are still open merge requests and bugs, but I'd like to get the
real testing started to see where we're at.

Please build, test, and upload binaries to the sftp. Let me know how
it goes. I'll upload source, docs, and your binaries to the
pre-release page once they're ready.


Hi Hans,

First wave of testing pass on ARM. Uploaded to the FTP server.

Is it time to do the back-ports planned? I only have a very minor bug fix.


Added as a dependency of http://llvm.org/PR28600, the release blockers metabug.



On the OpenMandriva side, x86_64 passes all checks. We’re having some problems with other architectures though (see below):

x86_64 succeeded, packages are here:

i586 fails to build, but this seems to be an issue with 3.8.1 (which we’re using to build 3.9):

The crash dump looks like it’s probably PR27071.
The bug was introduced in r261387 (which was merged into 3.8) and fixed in r264465 (which apparently wasn’t).

We're having some failures on AArch64, filed
28797 – [AArch64] Failures in Clang :: Driver/cl-pch-search.cpp and Clang :: Driver/cl-pch-showincludes.cpp and investigating.




Ouch :frowning:

Well, if we ever do a 3.8.2, that should be included. +Tom in case
he's maintaining a list.

Windows looked good. Binaries (sha1):
7f350f8a4903965ea9f3800f6d30a782ce86b0df LLVM-3.9.0-rc1-win32.exe
0b40f11a8d6c1f1fb69dcf213916cf439bb326c0 LLVM-3.9.0-rc1-win64.exe

Backported the v6T2/DSP patch. Now just needs to get Diana's AArch64
fix and we're fine.


Hi Bernhard,

Can you file a bug for this at www.llvm.org/bugs? Make sure to set
the version to 3.8 and assign it to me. You should also reference
PR27071 in the bug report.


Looks like Diana's fix was merged in r277462, so it sounds like we're all good.


Yup, we're good.


Uploaded clang+llvm-3.9.0-rc1-x86_64-linux-gnu-ubuntu-16.04.tar.xz

I had this error:

Using configuration variant: libcxxabi
– Testing: 35960 tests, 8 threads –
Testing: 0 … 10… 20… 30… 40… 50… 60… 70… *** stack smashing detected ***: /home/ben/development/llvm/3.9.0/rc1/Phase3/Release/llvmCore-3.9.0-rc1.obj/projects/compiler-rt/test/safestack/Output/canary.c.tmp.ssp terminated
80… 90…
Testing Time: 1695.83s
Expected Passes : 34915
Expected Failures : 212
Unsupported Tests : 833
[100%] Built target check-all

LNT was fine.


Fedora x64 looking good.

On x86 I’m getting an error about missing libclang_rt.asan_cxx-i686.a when running check-all, does anyone know what this is?

Maybe some confusion between i386 and i686 again? Do you have a libclang_rt.asan_cxx-i386.a somewhere in your build tree?


After fixing two compiler-rt test failures (see r277297 and r277300) and one openmp test link failure (see https://reviews.llvm.org/D23084), I'm left with only two failing tests:

Failing Tests (2):
    ThreadSanitizer-x86_64 :: inlined_memcpy_race2.cc
    ThreadSanitizer-x86_64 :: signal_reset.cc

  Expected Passes : 28511
  Expected Failures : 155
  Unsupported Tests : 1080
  Unexpected Failures: 2

These both fail because they hang indefinitely, and have to be killed for check-all to continue.

Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and higher, due to a conflict of initialization order with our jemalloc. So I am not extremely keen on fixing this before the release.

I uploaded the following:

SHA256 (clang+llvm-3.9.0-rc1-amd64-unknown-freebsd10.tar.xz) = 8d3b1d50c00901d235c110a84afa5c16f0e80683928a47e31f8c189a41268698
SHA256 (clang+llvm-3.9.0-rc1-i386-unknown-freebsd10.tar.xz) = 602373772b4ff2fc70c97f5483db33e3ecfd24122aed96d6fe083bae3ea0e6f6

For i386 and amd64, this contains llvm, clang, compiler-rt and lldb, while on amd64 there is also openmp. We cannot yet build libc++, libcxxabi and libunwind, due to some missing functionality in our system unwinder. Maybe if test-release.sh supported building libc++ separately, I could add it for the next RC.


This sounds really serious. Do we have a bug for that?


I'm not sure if it should be a compiler-rt bug or a FreeBSD bug. The issue is that __tsan_init() should be called before the initialization of malloc(), and that is not possible (or extremely difficult) with the version of jemalloc in FreeBSD 11 and 12.

The mechanism that TSan uses appears to be a .preinit_array section (though I'm not 100% sure it is used on FreeBSD):

__attribute__((section(".preinit_array"), used))
void (*__local_tsan_preinit)(void) = __tsan_init;

This section is then statically linked into the executable. However, jemalloc initializes through a constructor in libc.so:

static void


Since .so files which are required by an executable are *always* loaded and initialized before that executable, certainly for the .preinit_array section and the constructors, I am unsure how to solve this race. Maybe the solution is to link a small .so into the executable which is loaded even earlier than libc.so?

In the past I have tried several ways of working around this, could never get it to work, and then dropped it due to other priorities. But if anybody has good ideas, I am all ears. :slight_smile: