7.0.1-rc2 release has been tagged please begin testing

Hi,

The 7.0.1-rc2 release has been tagged and is ready for testing. I forgot
to bump the version number to 7.0.1 before I tagged -rc1, which is why we
are now on -rc2.

Remember, you can continue to submit merge requests up until Nov, 21,
so keep testing and submitting fixes.

Thanks,
Tom

Main test results on amd64-freebsd11 are mostly unchanged from 7.0.0 final, just a few more Expected Passes:

  Expected Passes : 52432 (7.0.0 final: 52422)
  Expected Failures : 232 (7.0.0 final: 232)
  Unsupported Tests : 3687 (7.0.0 final: 3687)
  Unexpected Passes : 1 (7.0.0 final: 1)
  Unexpected Failures: 489 (7.0.0 final: 489)

Test-suite results on amd64-freebsd11 did not change:

  Expected Passes : 903 (7.0.0 final: 903)
  Unexpected Failures: 3 (7.0.0 final: 3)

Test results on i386-freebsd11 were slightly better than 7.0.0 final, still due to a bunch of hanging lldb single step tests (these all seem to hang in the STOP state indefinitely, and so have to be killed off manually):

  Expected Passes : 50239 (7.0.0 final: 50226)
  Expected Failures : 226 (7.0.0 final: 226)
  Unsupported Tests : 2502 (7.0.0 final: 2502)
  Unexpected Failures: 274 (7.0.0 final: 277)

The test-suite still doesn't build on i386-freebsd11, but that is a known issue.

I have uploaded:

SHA256 (clang+llvm-7.0.1-rc2-amd64-unknown-freebsd11.tar.xz) = 4dfc76b7353701e23dc0b8ad54235c16066e3268b3b7bf77c7ad40acafa182fd
SHA256 (clang+llvm-7.0.1-rc2-i386-unknown-freebsd11.tar.xz) = 9bd92216dcee4b30e84dfdbdac149977fe7d4251f1d118da4410b561be4879a4

-Dimitry

Windows looks good. Binaries built with the attached batch file:

$ sha1sum *7.0.1-rc2*
d41253815eb3dd8184b73080350547f80b2decf2 LLVM-7.0.1-rc2-win32.exe
471c012e919988e475575cf25d251fcb329f9d42 LLVM-7.0.1-rc2-win64.exe

Cheers,
Hans

build_llvm_701-rc2.bat|attachment (4.09 KB)

Hi,

armv7a-linux-gnueabihf target is okay, there is just 10 more expected passes:

  Expected Passes : 49455 (7.0.0 final: 49445)
  Expected Failures : 231 (7.0.0 final: 231)
  Unsupported Tests : 2551 (7.0.0 final: 2551)

aarch64-linux-gnu target has also 10 more expected passes (the unexpected
failure is a none issue with our current docker image config and
name_to handle_at.cc test case):

  Expected Passes : 50841 (7.0.0 final: 50831)
  Expected Failures : 223 (7.0.0 final: 223)
  Unsupported Tests : 3067 (7.0.0 final: 3067)
  Unexpected Failures: 1 (7.0.0 final: 1)

But for AArch64 there is the following miscompare which I try to bisect:

# Comparing Phase 2 and Phase 3 files
file tsan_sync.cc.o differs between phase 2 and phase 3

I'll upload the tarballs when my access to the server will be granted.

Cheers,
Yvan

SLES binary uploaded:

181e1729263dcb1abc650311c4d42dbef13ae805 clang+llvm-7.0.1-rc2-x86_64-linux-sles11.3.tar.xz

… I will try to get to ubuntu this week.

Armv7a and AArch64 binaries uploaded:

0bb122ac8f39f1906c1c86d9fe00daed clang+llvm-7.0.1-rc2-aarch64-linux-gnu.tar.xz
d5b15005996517841e79b29b2502bd70
clang+llvm-7.0.1-rc2-armv7a-linux-gnueabihf.tar.xz

I'm still digging to find the cause of tsan miscompare on AArch64...

Hi,

Armv7a and AArch64 binaries uploaded:

0bb122ac8f39f1906c1c86d9fe00daed clang+llvm-7.0.1-rc2-aarch64-linux-gnu.tar.xz
d5b15005996517841e79b29b2502bd70
clang+llvm-7.0.1-rc2-armv7a-linux-gnueabihf.tar.xz

I'm still digging to find the cause of tsan miscompare on AArch64...

It took me a while to find it, but the miscompare of tsan_sync.cc.o on
AArch64 (small diff in regalloc and scheduling of a few instructions)
was due to the host compiler used in Phase1 (gcc 5.4), switching to
clang 6.0 fixed the problem.

Cheers,
Yvan

This broke the Zig build, because apt.llvm.org has the release candidate.

2018-11-25T16:53:30.7836235Z
/home/vsts/work/1/s/src/zig_llvm.cpp:686:1: error: static assertion
failed
2018-11-25T16:53:30.7837134Z
static_assert((Triple::OSType)ZigLLVM_LastOSType ==
Triple::LastOSType, "");
2018-11-25T16:53:30.7837409Z ^~~~~~~~~~~~~

I don't think the Triple::OSType enum should be changed across bugfix versions.

This is tricky to resolve because I cannot simply update zig source
code; this would make it incompatible with 7.0.0, and 7.0.1 has not
been released yet. Even after 7.0.1 is released it takes a bit of time
for various distros to pick up the change.

Can the change to add LLVM_HermitCore be reverted?

Regards,
Andrew

I double checked this information and here is what I have come up with:

There are no changes to include/llvm/ADT/Triple.h across 7.0.0 to 7.0.1:
andy@xps ~/downloads> diff -u llvm-7.0.0.src/include/llvm/ADT/Triple.h
llvm_release_70/include/llvm/ADT/Triple.h

So that's not a problem, and this is now off-topic in the subject line
of this email (7.0.1rc2 testing)

I believe that what happened is apt.llvm.org llvm-toolchain-xenial-7
was incorrectly updated with a version of LLVM that is not 7.0.0 or
7.0.1, and that's what broke the zig build.

This broke the Zig build, because apt.llvm.org has the release candidate.

2018-11-25T16:53:30.7836235Z
/home/vsts/work/1/s/src/zig_llvm.cpp:686:1: error: static assertion
failed
2018-11-25T16:53:30.7837134Z
static_assert((Triple::OSType)ZigLLVM_LastOSType ==
Triple::LastOSType, "");
2018-11-25T16:53:30.7837409Z ^~~~~~~~~~~~~

I don't think the Triple::OSType enum should be changed across bugfix versions.

This is tricky to resolve because I cannot simply update zig source
code; this would make it incompatible with 7.0.0, and 7.0.1 has not
been released yet. Even after 7.0.1 is released it takes a bit of time
for various distros to pick up the change.

Can the change to add LLVM_HermitCore be reverted?

Can you please file a bug for this and mark it as a release blocker.

-Tom