12.0.1-rc1 release has been tagged

Hi,

I've tagged the 12.0.1-rc1 release. Testers may upload binaries and report results.

-Tom

Windows looks good. The binaries are ready:

$ sha256sum LLVM-12.0.1-rc1-win*.exe
dc4ef18dc971a2ced2f42184da7de99eece7fe50863918f50588834f1612870d LLVM-12.0.1-rc1-win32.exe
39c35b4e2c737f4788474d17559fb8aa05cd3e2f613653ef759913a5e61a9a48 LLVM-12.0.1-rc1-win64.exe

Built with the attached script as usual.

Uploaded Ubuntu 21.04 with lldb.

sha256sum clang+llvm-12.0.1-rc1-x86_64-linux-gnu-ubuntu-21.04.tar.xz
e9d9dcf92870bfd52dc10dd34c4a04a6f6a188d0d396d7f996638d3c1456bb39

Failed Tests (15):
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.fstatat
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.stat
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.fstatat
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.stat
MemorySanitizer-X86_64 :: fstat.cpp
MemorySanitizer-lld-X86_64 :: fstat.cpp
SanitizerCommon-asan-i386-Linux :: Linux/crypt_r.cpp
SanitizerCommon-asan-i386-Linux :: Posix/crypt.cpp
SanitizerCommon-lsan-i386-Linux :: Linux/crypt_r.cpp
SanitizerCommon-lsan-i386-Linux :: Posix/crypt.cpp
SanitizerCommon-msan-x86_64-Linux :: Posix/lstat.cpp
SanitizerCommon-ubsan-i386-Linux :: Linux/crypt_r.cpp
SanitizerCommon-ubsan-i386-Linux :: Posix/crypt.cpp
libarcher :: races/lock-unrelated.c
lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py

Testing Time: 538.78s
Unsupported : 3416
Passed : 84233
Expectedly Failed: 267
Failed : 15

Submitted blocker bugs
50487 - TEST ‘MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.fstatat’ FAILED
50488 - TEST ‘MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.stat’ FAILED
50489 - TEST ‘MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.fstatat’ FAILED
50490 - TEST ‘MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.stat’ FAILED
50491 - TEST ‘MemorySanitizer-X86_64 :: fstat.cpp’ FAILED
50492 - TEST ‘MemorySanitizer-lld-X86_64 :: fstat.cpp’ FAILED
50493 - TEST ‘libarcher :: races/lock-unrelated.c’ FAILED

Not saying these bugs should be blockers. Only that it seems the place to put them.

Other fails in prior bugs.
48946 - skipping incompatible /usr/lib/x86_64-linux-gnu/libcrypt.so when searching for -lcrypt
48960 - FAIL: lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py

llvm-test-suite
Passed: 2405

Tests: 2825
Metric: exec_time

Program 12.0.0-rc5 12.0.1-rc1 diff
test-suite…/GCC-C-execute-20030120-1.test 0.00 0.00 inf%
test-suite…d_ops_test_op_pmulhuw_134.test 0.00 0.00 inf%
test-suite…d_ops_test_op_pmulhuw_181.test 0.00 0.01 inf%
test-suite…d_ops_test_op_pmulhuw_182.test 0.00 0.00 inf%
test-suite…/GCC-C-execute-20170419-1.test 0.00 0.00 inf%
test-suite…/GCC-C-execute-20171008-1.test 0.00 0.00 inf%
test-suite…/GCC-C-execute-20180112-1.test 0.00 0.00 inf%
test-suite…/GCC-C-execute-20180131-1.test 0.00 0.00 inf%
test-suite…te/GCC-C-execute-920625-1.test 0.00 0.00 inf%
test-suite…te/GCC-C-execute-920721-1.test 0.00 0.00 inf%
test-suite…md_ops_test_op_pmulhw_107.test 0.00 0.00 inf%
test-suite…te/GCC-C-execute-920731-1.test 0.00 0.00 inf%
test-suite…imd_ops_test_op_pmulhw_11.test 0.00 0.00 inf%
test-suite…te/GCC-C-execute-921204-1.test 0.00 0.00 inf%
test-suite…ute/GCC-C-execute-pr69447.test 0.00 0.00 inf%
Geomean difference nan%
12.0.0-rc5 12.0.1-rc1 diff
count 2807.000000 2807.000000 2784.000000
mean 210.572082 223.561162 inf
std 2830.933581 2825.553821 NaN
min 0.000000 0.000000 -1.000000
25% 0.000400 0.000400 -0.200000
50% 0.000500 0.000500 0.000000
75% 0.012950 0.011150 0.135624
max 79285.584375 85835.460625 inf

For 12.0.1 rc1, I have built and tested on both FreeBSD 11 and 12. No
additional patches were needed.

Main results on amd64-freebsd11:

  Unsupported : 5562 (12.0.0 final: 5562)
  Passed : 80189 (12.0.0 final: 80179)
  Expectedly Failed : 247 (12.0.0 final: 247)
  Timed Out : 2 (12.0.0 final: 2)
  Failed : 97 (12.0.0 final: 96)
  Unexpectedly Passed: 2 (12.0.0 final: 2)

Test suite results on amd64-freebsd11:

  Passed: 2399 (12.0.0 final: 2399)
  Failed: 3 (12.0.0 final: 3)

Main results on amd64-freebsd12:

  Unsupported : 5562 (12.0.0 final: 5562)
  Passed : 80194 (12.0.0 final: 80181)
  Expectedly Failed : 243 (12.0.0 final: 243)
  Timed Out : 2 (12.0.0 final: 3)
  Failed : 92 (12.0.0 final: 93)
  Unexpectedly Passed: 6 (12.0.0 final: 6)

Test suite results on amd64-freebsd12:

  Passed: 2399 (12.0.0 final: 2399)
  Failed: 3 (12.0.0 final: 3)

Main results on i386-freebsd11:

  Unsupported : 3976 (12.0.0 final: 3976)
  Passed : 76736 (12.0.0 final: 76723)
  Expectedly Failed : 224 (12.0.0 final: 224)
  Failed : 53 (12.0.0 final: 55)
  Unexpectedly Passed: 1 (12.0.0 final: 1)

Main results on i386-freebsd12:

  Unsupported : 3976 (12.0.0 final: 3976)
  Passed : 76739 (12.0.0 final: 76725)
  Expectedly Failed : 222 (12.0.0 final: 222)
  Failed : 50 (12.0.0 final: 53)
  Unexpectedly Passed: 3 (12.0.0 final: 3)

Uploaded:
SHA256 (clang+llvm-12.0.1-rc1-amd64-unknown-freebsd11.tar.xz) = 68ccfa684f181d69adc581c28cbc1d52a12396c444d3ba3543e99eb6e8b94d14
SHA256 (clang+llvm-12.0.1-rc1-amd64-unknown-freebsd12.tar.xz) = 6847c90d33eb8a597b372706fa1a9b6dac3ebcaffcd0b956287d0ac173ec8c50
SHA256 (clang+llvm-12.0.1-rc1-i386-unknown-freebsd11.tar.xz) = 7335ab91bfdab488071527345b4c5066544b34a0a11efd31f49ecf01ac08b096
SHA256 (clang+llvm-12.0.1-rc1-i386-unknown-freebsd12.tar.xz) = a20428ff308583f9d44f3f4eb86b720f3cd319592eb7805b54973f7b886cf862

-Dimitry

I've started testing, hit two bugs I've already reported for 12.0.0 RCs
and figured out I'm wasting my time. It seems that LLVM reached
the point where releases are pushed through just for the sake of
releases and QA doesn't exist.

Which bugs are these?

-Tom

The three I've hit immediately are:

https://bugs.llvm.org/show_bug.cgi?id=48918
https://bugs.llvm.org/show_bug.cgi?id=48937
https://bugs.llvm.org/show_bug.cgi?id=48939

Just to be clear, I'm not blaming you. But the whole release testing
process is just getting more and more frustrating.

Hello,

SHA1s:
Ubuntu: 229052e7ad72b9f8ad4b8d1a5c489a3a8c01a80a
RHEL: fc29b460ec5e1645819f5215d35e6d4fd4ff1ad3

clang+llvm-12.0.1-rc1-powerpc64le-linux-ubuntu-18.04.sha1 (102 Bytes)

clang+llvm-12.0.1-rc1-powerpc64le-linux-rhel-7.4.sha1 (98 Bytes)

Hello,

Sorry, to clarify - SHA1 for PowerPC8:
RHEL: fc29b460ec5e1645819f5215d35e6d4fd4ff1ad3
Ubuntu: 229052e7ad72b9f8ad4b8d1a5c489a3a8c01a80a

Albion

clang+llvm-12.0.1-rc1-powerpc64le-linux-rhel-7.4.sha1 (98 Bytes)

clang+llvm-12.0.1-rc1-powerpc64le-linux-ubuntu-18.04.sha1 (102 Bytes)

Hi,

I've tagged the 12.0.1-rc1 release. Testers may upload binaries and report results.

I've started testing, hit two bugs I've already reported for 12.0.0 RCs
and figured out I'm wasting my time. It seems that LLVM reached
the point where releases are pushed through just for the sake of
releases and QA doesn't exist.

Which bugs are these?

https://bugs.llvm.org/show_bug.cgi?id=49821

The fix for this has been in main branch since May 4, with a request to merge into release/12.x, and yet the release candidate does not include this, despite the bug open as a 12.0.1 release blocker.

Downstream we have our MIPS test suite disabled because of this bug. It was passing with LLVM 11.

Just to be clear, I'm not blaming you. But the whole release testing
process is just getting more and more frustrating.

I'm pretty frustrated over here too. What's the hurry on tagging releases? Can't we wait to tag releases until all the release blockers are fixed?

This is a compiler backend. Priority number one should be not introducing regressions. The timing of releases is not important at all in comparison.

Andrew

Hi,

For ARM, we still have the known cfi failures and one unexpected pass on (CodeGen/sanitize-coverage.c) seen on 12.0.0
and mentionned in https://bugs.llvm.org/show_bug.cgi?id=46117

There is also https://bugs.llvm.org/show_bug.cgi?id=50481 which was introduced into 12.0.0 and has a proposed fix
(https://reviews.llvm.org/D103167) which I think would be nice to have included in this release.

AArch64 are good, binaries uploaded:

sha256sum clang+llvm-12.0.1-rc1-a*
330b9ad17ad4538a8660e3cf115c449a8bb9acc42a86ec30c5927fabec7f2a4c clang+llvm-12.0.1-rc1-aarch64-linux-gnu.tar.xz
758190a1705281f97e5aa9c5e24d1fff8e1dace6377e8a2bdd21c8cbf36c4353 clang+llvm-12.0.1-rc1-armv7a-linux-gnueabihf.tar.xz

Cheers,
Yvan

In addition to the issues mentioned in this thread, I’d also like to ask if it would be possible to fix these two bugs as well:
https://bugs.llvm.org/show_bug.cgi?id=43604 (maybe unique to Debian packages)

https://bugs.llvm.org/show_bug.cgi?id=46321

Both of these are fixable exclusively by passing flags to CMake during the build, no source changes are needed here. Homebrew packages for Linux have fixed them now, but it’d be really great for the Linux distribution packages to have these fixes too.

I believe the only thing needed is to add the following to the RUNTIMES_CMAKE_ARGS list:
-DCMAKE_POSITION_INDEPENDENT_CODE=ON
-DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON
-DLIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY=OFF
-DLIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY=ON
-DLIBCXX_USE_COMPILER_RT=ON
-DLIBCXXABI_USE_COMPILER_RT=ON
-DLIBCXXABI_USE_LLVM_UNWINDER=ON

(Technically, the last three are not strictly necessary, but without them the installed libc++ and libc++abi libraries may fail due to missing features in libgcc_s on some Linux platforms and it seems both easy and beneficial to avoid this.)

If you have suggestion for improvements, I would be interested in hearing
those. The main problem that I see is that there needs to be a developer
interested in fixing a bug for it to get fixed. We (as a community) can do
more to help make developers aware of bugs (I'm hoping that moving to
GitHub issues will make this easier), but I don't know of a good way to
incentive developers to work on specific issues when it doesn't fit
into their normal day-to-day responsibilities.

-Tom

Hi,

I've tagged the 12.0.1-rc1 release. Testers may upload binaries and report results.

I've started testing, hit two bugs I've already reported for 12.0.0 RCs
and figured out I'm wasting my time. It seems that LLVM reached
the point where releases are pushed through just for the sake of
releases and QA doesn't exist.

Which bugs are these?

49821 – LLVM 12 regression: ld.lld: error: test.o:(.rodata.str1.1): offset is outside the section

The fix for this has been in main branch since May 4, with a request to merge into release/12.x, and yet the release candidate does not include this, despite the bug open as a 12.0.1 release blocker.

Downstream we have our MIPS test suite disabled because of this bug. It was passing with LLVM 11.

Sorry, I missed this one. The committer asked for us to wait until
the fix had been upstream for a while before backporting it, which
is why it was not backported right away.

In the future, if there is a bug you care about, I would recommend pinging
it once week if you aren't seeing movement on it.

Just to be clear, I'm not blaming you. But the whole release testing
process is just getting more and more frustrating.

I'm pretty frustrated over here too. What's the hurry on tagging releases? Can't we wait to tag releases until all the release blockers are fixed?

We usually don't have release blocking bugs. I know it's a little confusing,
because we use the 'blocks' field in bugzilla, but this is really used to mark
bugs that we want to fix, not bugs that must be fixed.

This is a compiler backend. Priority number one should be not introducing regressions. The timing of releases is not important at all in comparison.

I understand this position, but some people value a predictable release schedule
over more bug fixes from upstream and that's why we do time-based releases.

As I mentioned in the other mail, I think that moving to GitHub issues is
going to enable a lot of improvements in our release process. I think
with better automation and more process transparency we'll be able to
get more bugs fixed and provide a better experience for bug reporters,
developers, and release managers.

-Tom

Thanks for the reply, Tom. I'm looking forward to this.

Andrew