Hi,
I’ve tagged 14.0.0-rc1. Please upload the binaries to GitHub and report any bugs you find.
-Tom
I’m not managing to run this with the test-suite enabled. I’ve sent a patch to the test-release script: ⚙ D119322 test-release.sh: Remove test-suite from LLVM_ENABLE_PROJECTS
Yep - I am running into the same problem on macOS. Applied your edit for now.
Another “me too”:
CMake Error at CMakeLists.txt:84 (MESSAGE):
test-suite isn't a known project:
bolt;clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;polly;pstl;flang
-- Configuring incomplete, errors occurred!
See also "/home/dim/llvm/14.0.0/rc1/Phase1/Release/llvmCore-14.0.0-rc1.obj/CMakeFiles/CMakeOutput.log".
See also "/home/dim/llvm/14.0.0/rc1/Phase1/Release/llvmCore-14.0.0-rc1.obj/CMakeFiles/CMakeError.log".
Should I quickly do another release candidate with a fix or are we OK just working around this for -rc1 testing?
Maybe you can just repoint the rc1 tag to the fixed commit? Otherwise I think we can work around it. No need for rc2.
I’m starting work on the FreeBSD port and once I commit it, it will break if the hash of the distfile changes. If the tag is going to be slipped, please do it ASAP (I’d prefer we just skip to rc2).
I don’t think we should change tags once they have been created. I’ll just leave -rc1 as is then, and not do an -rc2 right away.
1 Like
macOS builds are up:
5e09b05781df6fb7f8f5427f019c13d84c449cfafc8efeb44e6471c431e8219c rc1/clang+llvm-14.0.0-rc1-x86_64-apple-darwin.tar.xz
Tests looks very clean for this release - just some ORC tests that fail:
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-cxa-atexit.S (959 of 10994)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-objc-methods.S (960 of 10994)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-tlv.S (961 of 10994)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-swift-types-section.S (969 of 10994)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-static-initializer.S (971 of 10994)
1 Like
On FreeBSD, the check-all phase fails to generate the CMake build files, with:
...
-- Performing Test LIBCXXABI_SUPPORTS_EHSC_FLAG
-- Performing Test LIBCXXABI_SUPPORTS_EHSC_FLAG - Failed
-- Performing Test LIBCXXABI_SUPPORTS_FUNWIND_TABLES_FLAG
-- Performing Test LIBCXXABI_SUPPORTS_FUNWIND_TABLES_FLAG - Success
-- Could not find ParallelSTL, libc++abi will not attempt to use it but the build may fail if the libc++ in use needs it to be available.
-- Performing Test LIBCXXABI_SUPPORTS_FVISIBILITY_EQ_HIDDEN_FLAG
-- Performing Test LIBCXXABI_SUPPORTS_FVISIBILITY_EQ_HIDDEN_FLAG - Success
-- Performing Test LIBCXXABI_SUPPORTS_FVISIBILITY_GLOBAL_NEW_DELETE_HIDDEN_FLAG
-- Performing Test LIBCXXABI_SUPPORTS_FVISIBILITY_GLOBAL_NEW_DELETE_HIDDEN_FLAG - Success
-- check-runtimes does nothing.
-- Configuring done
CMake Error at /home/dim/llvm/14.0.0/rc1/llvm-project/libcxx/src/CMakeLists.txt:340 (add_custom_command):
Error evaluating generator expression:
$<TARGET_LINKER_FILE:cxxrt>
No target "cxxrt"
CMake Error at /home/dim/llvm/14.0.0/rc1/llvm-project/libcxx/src/CMakeLists.txt:340 (add_custom_command):
Error evaluating generator expression:
$<TARGET_LINKER_FILE:cxxrt>
No target "cxxrt"
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
We’ve always used libcxxrt as C++ ABI library on FreeBSD, but for some reason this has now broke for the release script, or the way it builds the runtimes. @ldionne might have a clue… 
Uploaded AArch64 binaries:
db0451eddc5321ea56b5c7d96f958c271d8c7190f70c26e5f4091a34a4b59a90 14.0.0/clang+llvm-14.0.0-rc1-aarch64-linux-gnu.tar.xz
131eacf5db5b97ab55ba5fd18a072bdf0bdbb64ce5907333b6f935c60bd7256f 14.0.0/LLVM-14.0.0-rc1-woa64.zip
On Linux, we still have an LLDB issue that I’ve also seen for 13.x. I’ve also opened a few new issues:
- There’s one OpenMP test failing but it looks like it’s intended as an x86 test, so it probably just needs a stronger incantation to enable only when the host is x86.
- More lldb test failures
- 3 different object files between phase 2 and 3 (fuzzer-related)
I haven’t run the test-suite yet, but I’ll try to do that and report back only if I see failures.
I ran into some issues with the Armv7 build but they might be local, I’m still investigating.
1 Like
Windows is ready:
703bb8d6337e6ec6f41a4a5c41e56dc58dba4b7668d2d00272c86ac946a0be9c LLVM-14.0.0-rc1-win32.exe
f52c551effa7dce48c489b534475197baa344f956215ec26c385a94806ecd9d6 LLVM-14.0.0-rc1-win64.exe
The OpenMP runtime didn’t build (https://github.com/llvm/llvm-project/issues/53672 which is fixed now), so that’s not included in these packages. Hopefully it will be back in rc2.
1 Like
What’s the current methods for having patches backported to the release/14.x branch? I see that the “New Automated Release Workflow” documents are still RFC only. Building 14.0.0-rc1 on Solaris found a couple of issues that break the build one way or another.
The “no target cxxrt” error appears to have been introduced with @petrhosek 's [compiler-rt] Use the runtimes build for custom libc++ · llvm/llvm-project@458ead6 · GitHub (“[compiler-rt] Use the runtimes build for custom libc++”), which I could attempt to revert locally, but it is probably better to attempt to fix the root cause.
It seems that some of the sanitizers attempt to build their own ‘static’ copies of libc++, and it looks like it gets confused when the system ABI library is libcxxrt, but one of the LLVM_ENABLE_RUNTIMES is libc++abi.
I guess that for the test cases it is more logical to statically build against libc++abi, if you build everything else against it?
I am investigating different object files between Phase 2 and 3 on Linux for Release+Asserts:
# Comparing Phase 2 and Phase 3 files
file ArithmeticOps.cpp.o differs between phase 2 and phase 3
file TestPatterns.cpp.o differs between phase 2 and phase 3
as well as some PowerPC specific issues.
@DimitryAndric Can you share the script that you use to build your toolchain? The cxxrt error definitely seems like something that should work, I think it’s just that it’s not tested often so it regressed.
My initial testing on Gentoo amd64 yielded some regressions; for almost all of them I’ve opened backport requests but OCaml bugfix still needs someone to review it. Unfortunately, OpenMP has a large number of regressions that persist in main and I can’t even figure out where to start. To be honest, at this point I’m starting to think that packaging libomp was a mistake on our part.