13.0.0-rc1 has been tagged

Hi,

I've tagged the 13.0.0-rc1 release. Testers, please test and upload binaries.

-Tom

Uploaded Ubuntu 21.04 with lldb and flang.

ha256sum clang+llvm-13.0.0-rc1-x86_64-linux-gnu-ubuntu-21.04.tar.xz
ee9fb529893566a407f3eb69dcfc29f2552d91ddf605fbb37b6b998ef5485f5d

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
Profile-x86_64 :: Linux/binary-id.c
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
lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py

Testing Time: 803.97s
Skipped : 39
Unsupported : 4134
Passed : 96925
Expectedly Failed: 355
Failed : 15
make[3]: *** [CMakeFiles/check-all.dir/build.make:77: CMakeFiles/check-all] Error 1
make[3]: Target 'CMakeFiles/check-all.dir/build' not remade because of errors.
make[2]: *** [CMakeFiles/Makefile2:31829: CMakeFiles/check-all.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:31836: CMakeFiles/check-all.dir/rule] Error 2
make[1]: Target 'check-all' not remade because of errors.
make: *** [Makefile:283: check-all] Error 2
[Release+Asserts Phase3] check-all failed

New
Bug 51330 - FAIL: Profile-x86_64 :: Linux/binary-id.c

From before
Bug 50487 - TEST 'MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.fstatat' FAILED
Bug 50488 - TEST 'MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.stat' FAILED
Bug 50489 - TEST 'MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.fstatat' FAILED
Bug 50490 - TEST 'MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer.stat' FAILED
Bug 50491 - TEST 'MemorySanitizer-X86_64 :: fstat.cpp' FAILED
Bug 50492 - TEST 'MemorySanitizer-lld-X86_64 :: fstat.cpp' FAILED
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: 2425

Tests: 2882
Metric: exec_time

Program 12.0.1-rc4 13.0.0-rc1 diff
test-suite...ute/GCC-C-execute-align-1.test 0.00 0.00 inf%
test-suite...ute/GCC-C-execute-pr80153.test 0.00 0.00 inf%
test-suite...-C-execute-ieee-fp-cmp-8e.test 0.00 0.00 inf%
test-suite.../GCC-C-execute-20050131-1.test 0.00 0.00 inf%
test-suite...ute/GCC-C-execute-loop-11.test 0.00 0.00 inf%
test-suite...te/GCC-C-execute-950809-1.test 0.00 0.00 inf%
test-suite...d_ops_test_op_pcmpgtw_162.test 0.00 0.00 inf%
test-suite...te/GCC-C-execute-930614-2.test 0.00 0.00 inf%
test-suite...d_ops_test_op_pmaddwd_244.test 0.00 0.00 inf%
test-suite...-06-20-StaticBitfieldInit.test 0.00 0.00 inf%
test-suite...d_ops_test_op_pmaddwd_247.test 0.00 0.00 inf%
test-suite...te/GCC-C-execute-990826-0.test 0.00 0.00 inf%
test-suite...d_ops_test_op_pmaddwd_249.test 0.00 0.00 inf%
test-suite...md_ops_test_op_pmaxsb_304.test 0.00 0.00 inf%
test-suite...te/GCC-C-execute-memset-2.test 0.00 0.00 inf%
Geomean difference nan%
12.0.1-rc4 13.0.0-rc1 diff
count 2807.000000 2862.000000 2774.000000
mean 656.479029 214.059699 inf
std 10732.983747 2733.084686 NaN
min 0.000000 0.000000 -1.000000
25% 0.000400 0.000400 -0.304018
50% 0.000500 0.000500 0.000000
75% 0.044100 0.031950 0.250000
max 432134.864000 81665.029000 inf

Neil Nelson

Windows is ready:

$ sha256sum LLVM-13.0.0-rc1-win*.exe
809d574d63a267ec1a3dd1c4a9360b0879d2998fb619820d12ea0b31253b7e05 LLVM-13.0.0-rc1-win32.exe
057ea76cf65c36a2234f78641ba455dbae6a6996858aa94b7b72a5e1a22c3d92 LLVM-13.0.0-rc1-win64.exe

Built with the attached batch file.

There were some test failures in the 32-bit build. I won’t have time to dig into that before going on vacation, and I’m not sure how much it matters. The 32-bit Windows build is not tested regularly, so I’m thinking maybe we should stop shipping it.

check-llvm failures:

LLVM :: ExecutionEngine/MCJIT/load-object-a.ll
LLVM :: ExecutionEngine/RuntimeDyld/X86/coff-alignment.ll

check-clang failures:
Clang :: Interpreter/execute.cpp

check-clang-tools failures:

Clang Tools :: clang-tidy/checkers/modernize-use-nullptr-basic.cpp
Clang Tools :: clang-tidy/checkers/modernize-use-nullptr-cxx20.cpp
Clang Tools :: clang-tidy/checkers/modernize-use-nullptr.cpp
Clang Tools :: clang-tidy/infrastructure/clang-tidy-__clang_analyzer__macro.cpp
Clang Tools :: clang-tidy/infrastructure/clang-tidy-run-with-database.cpp
Clang Tools :: clang-tidy/infrastructure/read_file_config.cpp

build_llvm_1300-rc1.bat|attachment (5.04 KB)

Not sure if this is a supported configuration, but I am hitting this error when compiling on Ubuntu 16.04 with clang 12:

FAILED: /usr/local/bin/clang++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lldb/source/Plugins/ABI/ARM -I/__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM -Itools/lldb/source -I/__w/1/s/llvm-project/lldb/include -Itools/lldb/include -Iinclude -I/__w/1/s/llvm-project/llvm/include -I/__w/1/python/install/include/python3.9 -I/__w/1/s/llvm-project/llvm/…/clang/include -Itools/lldb/…/clang/include -I/__w/1/libxml2/install/include/libxml2 -I/__w/1/s/llvm-project/lldb/source/. -target x86_64-linux-gnu -fPIC -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -Os -DNDEBUG -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o -MF tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o.d -o tools/lldb/source/Plugins/ABI/ARM/CMakeFiles/lldbPluginABIARM.dir/ABIMacOSX_arm.cpp.o -c /__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp
In file included from /__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.cpp:9:
In file included from /__w/1/s/llvm-project/lldb/source/Plugins/ABI/ARM/ABIMacOSX_arm.h:12:
In file included from /__w/1/s/llvm-project/lldb/include/lldb/Target/ABI.h:12:
In file included from /__w/1/s/llvm-project/lldb/include/lldb/Core/PluginInterface.h:12:
In file included from /__w/1/s/llvm-project/lldb/include/lldb/lldb-private.h:15:
In file included from /__w/1/s/llvm-project/lldb/include/lldb/lldb-private-enumerations.h:12:
In file included from /__w/1/s/llvm-project/llvm/include/llvm/ADT/StringRef.h:12:
In file included from /__w/1/s/llvm-project/llvm/include/llvm/ADT/STLExtras.h:19:
In file included from /__w/1/s/llvm-project/llvm/include/llvm/ADT/Optional.h:18:
In file included from /__w/1/s/llvm-project/llvm/include/llvm/ADT/Hashing.h:48:
In file included from /__w/1/s/llvm-project/llvm/include/llvm/Support/ErrorHandling.h:18:
In file included from /usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/string:40:
In file included from /usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/char_traits.h:39:
In file included from /usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/stl_algobase.h:64:
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/stl_pair.h:134:35: error: call to implicitly-deleted copy constructor of ‘lldb_private::ThreadPlanStack’
: first(std::forward<_U1>(__x)), second(__y) { }
^ ~~~
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/ext/new_allocator.h:120:23: note: in instantiation of function template specialization ‘std::pair<const unsigned long, lldb_private::ThreadPlanStack>::pair<unsigned long &, void>’ requested here
{ ::new((void )__p) _Up(std::forward<_Args>(__args)…); }
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/alloc_traits.h:530:8: note: in instantiation of function template specialization ‘__gnu_cxx::new_allocator<std::pair<const unsigned long, lldb_private::ThreadPlanStack>>::construct<std::pair<const unsigned long, lldb_private::ThreadPlanStack>, unsigned long &, lldb_private::Thread &>’ requested here
{ __a.construct(__p, std::forward<_Args>(__args)…); }
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/hashtable_policy.h:1955:28: note: in instantiation of function template specialization ‘std::allocator_traits<std::allocator<std::pair<const unsigned long, lldb_private::ThreadPlanStack>>>::construct<std::pair<const unsigned long, lldb_private::ThreadPlanStack>, unsigned long &, lldb_private::Thread &>’ requested here
__value_alloc_traits::construct(__a, __n->_M_valptr(),
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/hashtable.h:1526:30: note: in instantiation of function template specialization ‘std::__detail::_Hashtable_alloc<std::allocator<std::__detail::_Hash_node<std::pair<const unsigned long, lldb_private::ThreadPlanStack>, false>>>::_M_allocate_node<unsigned long &, lldb_private::Thread &>’ requested here
__node_type
__node = this->_M_allocate_node(std::forward<_Args>(__args)…);
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/hashtable.h:726:11: note: in instantiation of function template specialization ‘std::_Hashtable<unsigned long, std::pair<const unsigned long, lldb_private::ThreadPlanStack>, std::allocator<std::pair<const unsigned long, lldb_private::ThreadPlanStack>>, std::__detail::_Select1st, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>>::_M_emplace<unsigned long &, lldb_private::Thread &>’ requested here
{ return _M_emplace(__unique_keys(), std::forward<_Args>(__args)…); }
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/bits/unordered_map.h:380:16: note: in instantiation of function template specialization ‘std::_Hashtable<unsigned long, std::pair<const unsigned long, lldb_private::ThreadPlanStack>, std::allocator<std::pair<const unsigned long, lldb_private::ThreadPlanStack>>, std::__detail::_Select1st, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>>::emplace<unsigned long &, lldb_private::Thread &>’ requested here
{ return _M_h.emplace(std::forward<_Args>(__args)…); }
^
/__w/1/s/llvm-project/lldb/include/lldb/Target/ThreadPlanStack.h:127:18: note: in instantiation of function template specialization ‘std::unordered_map<unsigned long, lldb_private::ThreadPlanStack, std::hash, std::equal_to, std::allocator<std::pair<const unsigned long, lldb_private::ThreadPlanStack>>>::emplace<unsigned long &, lldb_private::Thread &>’ requested here
m_plans_list.emplace(tid, thread);
^
/__w/1/s/llvm-project/lldb/include/lldb/Target/ThreadPlanStack.h:113:32: note: copy constructor of ‘ThreadPlanStack’ is implicitly deleted because field ‘m_stack_mutex’ has a deleted copy constructor
mutable std::recursive_mutex m_stack_mutex;
^
/usr/lib/gcc/x86_64-linux-gnu/5.4.0/…/…/…/…/include/c++/5.4.0/mutex:170:5: note: ‘recursive_mutex’ has been explicitly marked deleted here
recursive_mutex(const recursive_mutex&) = delete;
^
1 error generated.

That is certainly an odd chain of includes to end up complaining about ThreadPlanStacks...

ABIMacOSX.cpp does see the definition of ThreadPlanStacks but not along that path... Something got fairly confused.

There IS an implicitly deleted copy constructor for ThreadPlanStacks, but it doesn't get called anywhere. This is code that is built pretty much everywhere and this is the first time I've seen this error.

In the ThreadPlanStack header file, there are a couple of routines the iterate over the map of ThreadPlanStacks like (m_plans_list is: std::unordered_map<lldb:tid_t, ThreadPlanStack>):

  void ClearThreadCache() {
    for (auto &plan_list : m_plans_list)
      plan_list.second.ClearThreadCache();
  }

But those get "auto &" so they should just be pulling references to ThreadPlanStacks out, it shouldn't need to copy them.

And then we do call find on the ThreadPlanStackMap and do something with the iterator returned:

  bool RemoveTID(lldb::tid_t tid) {
    auto result = m_plans_list.find(tid);
    if (result == m_plans_list.end())
      return false;
    result->second.ThreadDestroyed(nullptr);
    m_plans_list.erase(result);
    return true;
  }

But the iterator of a map shouldn't require a copy of the value, that doesn't make sense.

Other than that, I can't see anything funny here.

Is this something triggered by -pedantic?

Jim

Not sure what’s up with clang’s inclusion chain reporting, but I found a couple of SO threads 1 2 regarding the need of the copy constructor: apparently, until GCC 6, std::unordered_map could not emplace non-copyable values. Following the advice in 2, I was able to overcome the error by rewriting ThreadPlanStack::AddThread like this:

void AddThread(Thread &thread) {
lldb::tid_t tid = thread.GetID();
m_plans_list.emplace(std::piecewise_construct,
std::forward_as_tuple(tid),
std::forward_as_tuple(thread));
}

Once again we see the elegance of C++ never failing to impress...

I wonder if it wouldn't be simpler to make a copy constructor that just makes a new mutex. The ThreadPlanStack is a vector of ThreadPlan shared pointers, so it is cheap to copy, and the stack just uses the mutex internally, so making a new one would be fine. Slightly less efficient, but then we wouldn't have to deal with this sort of silliness.

But otherwise, if this is necessary, I have opinions but no serious objections to this change. Feel free to put up a patch.

Jim

Hi Tom,

I’m seeing a lot of test failures, but most importantly, the test-release.sh script fails to build any binary for both powerpc OSes (Ubuntu and RHEL). This is using 12.0.0 to build, we’re still investigating.

A quick list of regressions we’re seeing:

libc++ :: std/numerics/numeric.ops/numeric.ops.midpoint/midpoint.float.pass.cpp
libc++ :: libcxx/atomics/atomics.align/align.pass.cpp.

On RHEL:

compiler-rt/lib/scudo/standalone/tests/ScudoCxxUnitTest-powerpc64le-Test
compiler-rt/lib/scudo/standalone/tests/ScudoCUnitTest-powerpc64le-Test

due to (on Linux RHEL, so this one is weird):

ld.lld: error: unable to find library -latomic

There’s this concerning build failure of an open source Google benchmark:

Benchmarks/snappy/src/third_party/benchmark/src/complexity.cc:85:10: error: variable 'sigma_gn' set but not used [-Werror,-Wunused-but-set-variable]
  double sigma_gn = 0.0;
         ^
1 error generated.

when it’s clearly used in the lines immediately after it: https://github.com/google/benchmark/blob/bf585a2789e30585b4e3ce6baf11ef2750b54677/src/complexity.cc

We’re also seeing other SPEC benchmark failures and some internal benchmark failures, and finally test-release.sh fails:

UNREACHABLE executed at /home/conanap/upload/rc1/llvm-project/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp:182!
PLEASE submit a bug report to [https://bugs.llvm.org/](https://bugs.llvm.org/) and include the crash backtrace, preprocessed source, and associated run script.

The 13.0.0rc1 is built with 12.0.0 here, so I’ll try building with 11.0.0 to see if I will encounter some of the same errors (test-release.sh fails even with 11.0.0 compilers). We’re otherwise still investigating the rest of the errors.

Albion

Hi Tom,

I'm seeing a lot of test failures, but most importantly, the test-release.sh script fails to build any binary for both powerpc OSes (Ubuntu and RHEL). This is using 12.0.0 to build, we're still investigating.

A quick list of regressions we're seeing:

Can you file bugs for these so we can track them (put release-13.0.0 in the 'blocks' field).

Thanks,
Tom

Hi Tom,

I’ve created the bugzilla bugs. We were able to generate the binaries with -no-clang, here are the checksums:
RHEL: 88606380909b9ec06b8ad4f28136e55a642d9b2e
Ubuntu: f16dd31408436630812c42dec55bbc338bde1c0e

Albion

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

clang+llvm-13.0.0-rc1-powerpc64le-linux-ubuntu-18.04.sha1 (106 Bytes)

For 13.0.0 rc1, I have built and tested on both FreeBSD 12 and 13. I
used 6 patches, which are attached. (Most of these are already merged
for the next rc.)

For the 32-builds I used -no-flang, as flang is currently not 32-bit
clean, and I do not expect it will ever be.

Main results on amd64-freebsd12:

  Skipped : 3
  Unsupported : 6352
  Passed : 91852
  Expectedly Failed : 320
  Timed Out : 2
  Failed : 290
  Unexpectedly Passed: 2

Test suite results on amd64-freebsd12:

  Passed: 2419
  Failed: 3

Main results on amd64-freebsd13:

  Skipped : 3
  Unsupported : 6352
  Passed : 91815
  Passed With Retry : 1
  Expectedly Failed : 320
  Timed Out : 1
  Failed : 327
  Unexpectedly Passed: 2

Test suite results on amd64-freebsd13:

  Passed: 2419
  Failed: 3

Main results on i386-freebsd12:

  Skipped : 3
  Unsupported : 4735
  Passed : 87533
  Expectedly Failed : 295
  Failed : 201
  Unexpectedly Passed: 1

Main results on i386-freebsd13:

  Skipped : 3
  Unsupported : 4735
  Passed : 87532
  Expectedly Failed : 295
  Failed : 202
  Unexpectedly Passed: 1

Uploaded:
SHA256 (clang+llvm-13.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = 49bd21a069e655b42ba017520357db6cf119108cd6b6c3fa407b95675721051f
SHA256 (clang+llvm-13.0.0-rc1-amd64-unknown-freebsd13.tar.xz) = 9bb9b6b4a4790f5410f42bfc43accffa07699a6a0414ae8917243d0da7a34d6b
SHA256 (clang+llvm-13.0.0-rc1-i386-unknown-freebsd12.tar.xz) = e8feda2f48a51572d0fa1649e7f49b5cf3e2e7fb6c54274d02208c9ae01564ff
SHA256 (clang+llvm-13.0.0-rc1-i386-unknown-freebsd13.tar.xz) = e9f187a47106ce8269363e31af0c6f1961f8b692b28e5bfb610b66e093b6f393

-Dimitry

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

fix-compiler-rt-2.diff (501 Bytes)

fix-mlir-1.diff (476 Bytes)

fix-openmp-1.diff (635 Bytes)

fix-openmp-2.diff (1.04 KB)

fix-test-suite-1.diff (1.03 KB)

Tom,

Uploaded rc1 for macOS now. I had to pass -no-flang because of
compilation issue that can be fixed by picking this commit from the
main branch: https://github.com/llvm/llvm-project/commit/4573c31f8945071d0069dcad31e17ddfeb7a2d8c#diff-e0739e26e14afec3303877447d7d5c8c9374825c177d2905b5c8232decfbe2bf

SHA-256: ff0891aa05b8fb365f0e069873153111491f3d4e8345ebfd98b05f90da951c4b
clang+llvm-13.0.0-rc1-x86_64-apple-darwin.tar.xz

Many tests failed, especially in lldb:

FAIL: AddressSanitizer-x86_64-darwin ::
TestCases/Posix/lto-constmerge-odr.cpp (669 of 96071)
FAIL: AddressSanitizer-x86_64h-darwin ::
TestCases/Posix/lto-constmerge-odr.cpp (1167 of 96071)
FAIL: libomp :: affinity/root-threads-affinity.c (90694 of 96071)
FAIL: libomp ::
ompt/loadtool/tool_available_search/tool_available_search.c (90761 of
96071)
FAIL: libomp :: tasking/hidden_helper_task/gtid.cpp (90858 of 96071)
FAIL: libomp :: worksharing/for/kmp_sch_simd_guided.c (90901 of 96071)
FAIL: libunwind :: signal_frame.pass.cpp (90956 of 96071)
FAIL: lldb-shell :: Commands/command-thread-select.test (94817 of 96071)
FAIL: lldb-shell :: Breakpoint/jit-loader_jitlink_elf.test (94818 of 96071)
FAIL: lldb-shell :: Breakpoint/jit-loader_rtdyld_elf.test (94819 of 96071)
FAIL: lldb-shell :: ExecControl/StopHook/stop-hook.test (94823 of 96071)
FAIL: lldb-shell :: Host/TestCustomShell.test (94842 of 96071)
FAIL: lldb-shell :: Expr/TestIRMemoryMap.test (94849 of 96071)
FAIL: lldb-shell :: Process/Optimization.test (94852 of 96071)
FAIL: lldb-shell :: Process/UnsupportedLanguage.test (94853 of 96071)
FAIL: lldb-shell :: Process/TestEnvironment.test (94854 of 96071)
FAIL: lldb-shell :: Register/x86-64-gp-read.test (94855 of 96071)
FAIL: lldb-shell :: Register/x86-64-read.test (94862 of 96071)
FAIL: lldb-shell :: Register/x86-64-ymm-read.test (94866 of 96071)
FAIL: lldb-shell :: Register/x86-multithread-read.test (94873 of 96071)
FAIL: lldb-shell :: Register/x86-multithread-write.test (94876 of 96071)
FAIL: lldb-shell :: Reproducer/Functionalities/TestImageList.test
(94879 of 96071)
FAIL: lldb-shell :: Reproducer/Functionalities/TestDataFormatter.test
(94880 of 96071)
FAIL: lldb-shell ::
Reproducer/Functionalities/TestExpressionEvaluation.test (94882 of
96071)
FAIL: lldb-shell :: Reproducer/Functionalities/TestStepping.test
(94883 of 96071)
FAIL: lldb-shell :: Reproducer/Modules/TestModuleCXX.test (94884 of 96071)
FAIL: lldb-shell :: Reproducer/TestDSYM.test (94902 of 96071)
FAIL: lldb-shell :: Reproducer/TestDump.test (94922 of 96071)
FAIL: lldb-shell :: Reproducer/TestFileRepro.test (94924 of 96071)
FAIL: lldb-shell :: Reproducer/TestGDBRemoteRepro.test (94931 of 96071)
FAIL: lldb-shell :: Reproducer/TestMultipleTargets.test (94932 of 96071)
FAIL: lldb-shell :: Reproducer/TestRelativePath.test (94934 of 96071)
FAIL: lldb-shell :: Reproducer/TestReuseDirectory.test (94946 of 96071)
FAIL: lldb-shell :: Reproducer/TestVersionCheck.test (94947 of 96071)
FAIL: lldb-shell :: Reproducer/TestVerify.test (94948 of 96071)
FAIL: lldb-shell :: Reproducer/TestWorkingDir.test (94950 of 96071)
FAIL: lldb-shell :: Settings/TestFrameFormatColor.test (94957 of 96071)
FAIL: lldb-shell :: Settings/TestFrameFormatMangling.test (94961 of 96071)
FAIL: lldb-shell :: Settings/TestFrameFormatNoColor.test (94969 of 96071)
FAIL: lldb-shell :: Settings/TestLineMarkerColor.test (94975 of 96071)
FAIL: lldb-shell :: Subprocess/fork-follow-parent-wp.test (95010 of 96071)
FAIL: lldb-shell :: Subprocess/fork-follow-parent.test (95032 of 96071)
FAIL: lldb-shell :: Subprocess/vfork-follow-parent.test (95045 of 96071)
FAIL: lldb-shell :: SymbolFile/DWARF/deterministic-build.cpp (95046 of 96071)
FAIL: lldb-shell :: Unwind/eh-frame-dwarf-unwind.test (95219 of 96071)
FAIL: lldb-shell :: Unwind/thread-step-out-ret-addr-check.test (96063 of 96071)
FAIL: lldb-shell :: Unwind/trap_frame_sym_ctx.test (96066 of 96071)
FAIL: lldb-shell :: Watchpoint/SetErrorCases.test (96067 of 96071)
FAIL: lldb-unit ::
tools/lldb-server/tests/./LLDBServerTests/StandardStartupTest.TestStopReplyContainsThreadPcs
(96068 of 96071)

AddressSanitizer, libomp and libunwind are NOT regressions in this
release - while the LLDB ones are.

-- Tobias

Hi,

Uploaded aarch64 and armv7 binaries:
77485e0e3660ab15644cc0256597035747d407baeb8e4a849792a4162928276d clang+llvm-13.0.0-rc1-aarch64-linux-gnu.tar.xz
c233fb82060698690ec5629ff5f3d88dae6dec35031545c413dd1de424301ced clang+llvm-13.0.0-rc1-armv7a-linux-gnueabihf.tar.xz

These were built by Omair Javaid while I was out of office - thanks, Omair :slight_smile:

Armv7 has the same CFI issues as always (not a release blocker), and AArch64 now has some lldb-related failures reported by Omair here: https://bugs.llvm.org/show_bug.cgi?id=51446

Cheers,
Diana

Hi Tom,

Due to an error on our part, we had to reupload the RHEL binaries (named for RHEL7.4). Please disregard the previously uploaded binaries. This is the new hash:
31c5cb888a0df98fa1d13267de6e5f260aba46eb

Thanks,
Albion

clang+llvm-13.0.0-rc1-powerpc64le-linux-rhel-7.9.sha1 (98 Bytes)

Hi,

I’ve uploaded Windows-on-arm binaries (built by my colleague Maxim Kuvyrkov):
f78254d24a93e5215f0885c681670ae870548c31e84983ac7610e6e6a24b329b LLVM-13.0.0-rc1-woa64.zip

No release blockers to report :slight_smile:

Cheers,
Diana