Hi,
I’ve just tagged 14.0.0-rc4, please test and upload the binaries. If everything goes well, this will be the last release candidate.
Also, the reason there was no -rc3 release was because there was a bug discovered right after I tagged -rc3, so I didn’t want to have everyone test a known buggy build.
Hi,
CMake doesn’t like this:
CMake Error at /home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-jade-03/rc4/llvm-project/compiler-rt/cmake/base-config-ix.cmake:189 (add_default_target_arch):
add_default_target_arch Macro invoked with incorrect arguments for macro
named: add_default_target_arch
Call Stack (most recent call first):
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-jade-03/rc4/llvm-project/compiler-rt/cmake/config-ix.cmake:210 (test_targets)
/home/tcwg-buildslave/workspace/tcwg-llvm-release/tcwg-jade-03/rc4/llvm-project/compiler-rt/CMakeLists.txt:251 (include)
and something similar for get_compiler_rt_output_dir.
I’m using the command that worked for rc2:
./test-release.sh -release 14.0.0 -rc 4 -triple aarch64-linux-gnu -j64 -use-ninja -configure-flags '-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON -DLLVM_LIT_ARGS=-svj16'
Is anyone else hitting something similar?
macOS binaries:
6604520aefa4f43b739867d781b8b81950e52dce392fff39c01eb2196eb3e65d clang+llvm-14.0.0-rc4-x86_64-apple-darwin.tar.xz
Failing tests:
FAIL: Clang :: Driver/darwin-ld-lto.c (8201 of 99378)
FAIL: Flang :: Runtime/no-cpp-dep.c (33368 of 99378)
FAIL: LLVM :: ExecutionEngine/JITLink/X86/MachO_x86-64_self_relocation_exec.test (56518 of 99378)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-cxa-atexit.S (82471 of 99378)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-static-initializer.S (82472 of 99378)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-tlv.S (82473 of 99378)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-objc-methods.S (82474 of 99378)
FAIL: ORC-x86_64-darwin :: TestCases/Darwin/x86-64/trivial-swift-types-section.S (82480 of 99378)
FAIL: flang-OldUnit :: Evaluate/folding.test (85817 of 99378)
FAIL: libomp :: ompt/loadtool/tool_available_search/tool_available_search.c (94057 of 99378)
FAIL: libomp :: tasking/hidden_helper_task/gtid.cpp (94167 of 99378)
FAIL: libomp :: worksharing/for/kmp_sch_simd_guided.c (94218 of 99378)
Nothing new over rc2
For 14.0.0 rc4, I have built and tested on both FreeBSD 12 and 13. No additional patches were needed.
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.
After commit df2fcea78fb8, which reverted the bootstrapping build, the number of regression tests is again back to normal.
Main results on amd64-freebsd12:
Skipped : 4 (rc1: 0)
Unsupported : 6771 (rc1: 3368)
Passed : 96999 (rc1: 11464)
Passed With Retry : 1 (rc1: 1)
Expectedly Failed : 314 (rc1: 86)
Timed Out : 5 (rc1: 0)
Failed : 171 (rc1: 117)
Unexpectedly Passed: 0 (rc1: 2)
Test suite results on amd64-freebsd12:
Passed: 2420 (rc1: 2420)
Failed: 3 (rc1: 3)
Main results on amd64-freebsd13:
Skipped : 4 (rc1: 0)
Unsupported : 6771 (rc1: 3368)
Passed : 96962 (rc1: 11461)
Expectedly Failed : 314 (rc1: 86)
Timed Out : 5 (rc1: 0)
Failed : 209 (rc1: 121)
Unexpectedly Passed: 2 (rc1: 2)
Test suite results on amd64-freebsd13:
Passed: 2420 (rc1: 2420)
Failed: 3 (rc1: 3)
Main results on i386-freebsd12:
Skipped : 4 (rc1: 0)
Unsupported : 5127 (rc1: 1925)
Passed : 92085 (rc1: 8255)
Passed With Retry : 1 (rc1: 0)
Expectedly Failed : 284 (rc1: 68)
Timed Out : 2 (rc1: 0)
Failed : 182 (rc1: 164)
Unexpectedly Passed: 1 (rc1: 1)
Main results on i386-freebsd13:
Skipped : 4 (rc1: 0)
Unsupported : 5127 (rc1: 1925)
Passed : 92080 (rc1: 8251)
Passed With Retry : 0 (rc1: 1)
Expectedly Failed : 284 (rc1: 68)
Timed Out : 2 (rc1: 0)
Failed : 188 (rc1: 167)
Unexpectedly Passed: 1 (rc1: 1)
Uploaded:
SHA256 (clang+llvm-14.0.0-rc4-amd64-unknown-freebsd12.tar.xz) = 4540e765fd222da55ce5682147e4b8ad410494721eebde489bdb4a979d843866
SHA256 (clang+llvm-14.0.0-rc4-amd64-unknown-freebsd13.tar.xz) = 2cd4f927491f2fa0b63febfbc43db9196ac7ad05a3b56315cf7b870db11857d6
SHA256 (clang+llvm-14.0.0-rc4-i386-unknown-freebsd12.tar.xz) = 5b93208c05727ffb4ea5ae6f0662c62be174b5e6c9b3a10991dba96783344619
SHA256 (clang+llvm-14.0.0-rc4-i386-unknown-freebsd13.tar.xz) = 4113c4c53ad5a85e67e16498685866433addfd61e52913f16721bd8669b3d7fe
-Dimitry
Windows is ready. The binaries were built with the attached batch file.
build_llvm_1400-rc4.bat.txt (5.2 KB)
sha256 hashes:
a1e37a6e0d66da6dbe32af4ebdb905884395663773299008d33027537a546327 LLVM-14.0.0-rc4-win32.exe
4b7679beada7fafea189651863ca44c80112e21b8df47d035f24b3ea80f84f0d LLVM-14.0.0-rc4-win64.exe
@tstellar: This seems to be because of the changes to test-release.sh. It’s behaving a bit strangely, in the sense that for rc2 it said that compiler-rt and libcxx & co were disabled (I didn’t notice this because it was running the tests for them anyway…), but now for rc4 it says they’re enabled and it errors out because COMPILER_RT_DEFAULT_TARGET_ARCH is empty. I can work around this by setting CMAKE_C_COMPILER_TARGET, but that’s probably not a very principled fix. In any case, the builds are in progress now, I’ll post the results as soon as they’re ready.
I’ve now uploaded Solaris/amd64 and Solaris/sparcv9 binaries:
sha256 hashes:
d00c7b4b666b031fb4cf45746139b063b60652eac84cf7d6ed4d7caa3bff9b64 clang+llvm-14.0.0-rc4-amd64-pc-solaris2.11.tar.xz
46ce4379eeb2ed6e84af2dbb20ac24a3478c2126fca31db892042b32c288e3ac clang+llvm-14.0.0-rc4-sparcv9-sun-solaris2.11.tar.xz
No regressions compared to rc2.
I’m working on a patch for Issue #54196, which will be needed for 14.0.1 when it switches back to -DLLVM_ENABLE_RUNTIMES.
I’ve also run an x86_64-pc-linux-gnu build for good measure, but unlike rc2 that won’t build with the bundled GCC 9.3.0 (or 10.3.0) in Ubuntu 20/04. libcxxabi/src/cxa_aux_runtime.cpp FAILs to compile in Phase 1:
/var/llvm/reltest/llvm-14.0.0-rc4/rc4/Phase1/Release/llvmCore-14.0.0-rc4.obj/include/c++/v1/type_traits:554:53: error: there are no arguments to ‘__is_same’ that depend on a template parameter, so a declaration of ‘__is_same’ must be available [-fpermissive]
554 | struct _LIBCPP_TEMPLATE_VIS is_same : _BoolConstant<__is_same(_Tp, _Up)> { };
|
I have no idea which version of GCC is required to build.
Hi!
I am aware that rG26a1830e39ba (Using the Bootstrapping Build for LLVM releases) was reverted due to an issue, and then recommitted along with a fix. Then, I noticed the patch (along with the fix) was reverted once again prior to tagging rc4.
The removal of this patch: rG26a1830e39ba makes us unable to build on AIX (since we build compiler-rt as run times). As a result, I have reapplied that patch to my rc4 source since it allows me to build rc4 successfully.
I think we will need to find a solution for the runtimes issue that can work, or unfortunately, we will have to provide a build that deviates from the actual source in the release branch. 
I’ve uploaded the PowerPC (AIX 7.2) binary for rc4 that I’ve built.
622c8418f1a83dadab200e061effb71e7d33f54f clang+llvm-14.0.0-rc4-powerpc64-ibm-aix-7.2.tar.xz
Aside from the issue I mentioned previously, no new regressions were seen when testing RC4 on AIX.
@amy-kwan Does @rovka’s suggestion in 14.0.0-rc4 has been tagged - #6 by rovka fix the failure for you?
Hi @tstellar,
Thanks for the suggestion. The solution of setting CMAKE_C_COMPILER_TARGET does not work for me if I try to rebuild without the patch. My error is actually not at the CMake stage, though - it’s during the stage 1 build step.
We’re unable to build parts of compiler-rt when setting it as a project on AIX - so we usually build compiler-rt as a runtime (which is what rG26a1830e39ba helped accomplish before).
@amy-kwan Is this just an issue with the test-release.sh script or is it impossible to build on AIX at all?
@tstellar, I suppose it could be a little bit of both.
In terms of test-release.sh, the script currently defaults to building compiler-rt as a project (I was able to use the test-release.sh script when the patch I mentioned earlier was committed, since it added compiler-rt to -DLLVM_ENABLE_RUNTIMES).
With the build compiler we use, I am not able to build on AIX when compiler-rt is built as a project, due to build errors in compiler-rt that occur.
We’ve pretty much only been building LLVM on AIX when compiler-rt is built as a runtime, and I have really only been able to get a successful run of test-release.sh on AIX with compiler-rt in -DLLVM_ENABLE_RUNTIMES (so really, we’re able to build compiler-rt with the just-built compiler).
Out of interest, what kind of compiler-rt build errors are you getting? Are these errors occurring because now the library is compiled using the host compiler (which I assume is an AIX specific thing), instead of clang?
Finally managed to upload:
49a1b1bac50e31127b606b09b9343b0750df9dbbe1b6855eff9c22a5c3702ef5 clang+llvm-14.0.0-rc4-aarch64-linux-gnu.tar.xz
637e3ca7c7b0d58392320b8108bb570e4b81242f7dbfc22127b56c0b6aa1a619 clang+llvm-14.0.0-rc4-armv7a-linux-gnueabihf.tar.xz
c754b4e1d3ab61b24f51e6025d73478e5ab9b2f9fbad64ea631413e250e52a89 LLVM-14.0.0-rc4-woa64.zip
In general it looks a lot like rc2, but:
I’ve uploaded PowerPC Linux binaries:
e0a2380306ddc9b0fbe424214f652493361bae84 clang+llvm-14.0.0-rc4-powerpc64le-linux-rhel-7.9.tar.xz
5e691a043df91aa346016740aff56079d836c9d7 clang+llvm-14.0.0-rc4-powerpc64le-linux-ubuntu-18.04.5.tar.xz
For RHEL only, I ran into a build error during ninja check-all for both Release and Release+Asserts. Here is the error:
FAILED: tools/flang/unittests/Runtime/CMakeFiles/FlangRuntimeTests.dir/Time.cpp.o
/scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/Phase2/Release/llvmCore-14.0.0-rc4.install/usr/local/bin/clang++ -DFLANG_LITTLE_ENDIAN=1 -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/flang/unittests/Runtime -I/scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/flang/unittests/Runtime -I/scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/flang/include -Itools/flang/include -Iinclude -I/scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/llvm/include -I/scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/llvm/utils/unittest/googletest/include -I/scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/llvm/utils/unittest/googlemock/include -isystem /scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/llvm/../mlir/include -isystem tools/mlir/include -isystem tools/clang/include -isystem /scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/llvm/../clang/include -fPIC -fno-semantic-interposition -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 -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-copy -Wno-string-conversion -Wno-unused-command-line-argument -Wstring-conversion -Wcovered-switch-default -Wno-nested-anon-types -O3 -DNDEBUG -fPIE -Wno-variadic-macros -Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -Wno-suggest-override -std=c++17 -MD -MT tools/flang/unittests/Runtime/CMakeFiles/FlangRuntimeTests.dir/Time.cpp.o -MF tools/flang/unittests/Runtime/CMakeFiles/FlangRuntimeTests.dir/Time.cpp.o.d -o tools/flang/unittests/Runtime/CMakeFiles/FlangRuntimeTests.dir/Time.cpp.o -c /scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/flang/unittests/Runtime/Time.cpp
/scratch/quinnp/llvm/llvmorg-14.0.0-rc4_uploaded/rc4/llvm-project/flang/unittests/Runtime/Time.cpp:13:10: fatal error: 'charconv' file not found
#include <charconv>
^~~~~~~~~~
1 error generated.
I’m not sure, but this seems to be related to building certain things as projects instead of runtimes similar to the issues that @amy-kwan encountered. I was able to run test-release.sh successfully after re-applying rG26a1830e39ba.The binary I’ve uploaded for PowerPC RHEL was built using that modified version of test-release.sh.
Besides this, there were no new failures.
This looks like your host system’s compiler (the RHEL one) does not have the <charconv> header. If you have access to the so-called “devtoolset” packages, you could attempt to install a newer version, and use that as the host compiler. RHEL even supports this officially.
Or if you want to build with clang, you can use the llvm-toolset packages on RHEL.
Ah, but as far as I know these still have to be able to find newer libstdc++ versions, which are only available via the devtoolset packages? (Maybe you could also build against libc++, but then your executables would become dependent on a libc++ runtime package, and they wouldn’t be interoperable with libstdc+±dependent packges.)
Oh you are right, thanks @DimitryAndric and @tstellar! I’ll look into that more.
Right, llvm-toolset should pull in the newer devtools libstdc++ in as a dependency, and the clang driver will find it: https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Gnu.cpp#L2046
libc++ is not available in RHEL.