14.0.0-rc4 has been tagged

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

1 Like

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

1 Like

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
1 Like

@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.

2 Likes

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. :frowning:

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.

2 Likes

@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:

  • On AArch64 Linux, I’m seeing some new libarcher failures. These seem to be because the addr2line on the machine is too old, so I wouldn’t consider it a release blocker.
  • On armv7 I’m seeing some new lldb failures in the libcxx-related tests. These are probably a consequence of how libcxx is built (project vs runtime), so again I wouldn’t consider this a blocker. On the bright side, I’m no longer seeing any differences between Phase2 and Phase3 objects.
1 Like

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.

1 Like

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: llvm-project/Gnu.cpp at main · llvm/llvm-project · GitHub

libc++ is not available in RHEL.