ping

Added nvptx-nvidia builders into the patch.

They are not ready yet, but ok.

@gkistanova
these new workers have the same access token as all our as-builder-* workers.

@ldionne ,
I have checked out our cmake cache for win-to-linux cross builds and I found that we already use the "new-style" test configuration files all libs accordingly: llvm-libc++-static.cfg.in, llvm-libc++abi-static.cfg.in and llvm-libunwind-static.cfg.in. It works fine for the builds currently.
We provide <lib>_TARGET_INFO=libcxx.test.target_info.LinuxRemoteTI and <lib>_EXECUTOR cmake vars only for these configurations.
Actually, the tests work without <lib>_TARGET_INFO also, but because there is still an appropriate parameter I did keep them there just in case.

Hi @ldionne. Got it, thank you! I'll check our cmake cache file out and remove any deprecated variables.

got it. Yes, looks like it fixed. The test got passed during the last build: https://lab.llvm.org/buildbot/#/builders/104/builds/7812
Thank you.

the zero-call-used-regs.ll test gets failed on llvm-clang-x86_64-expensive-checks-ubuntu builder with the following errors:

...
*** Bad machine code: Illegal physical register for instruction ***
- function:    all_arg
- basic block: %bb.0 entry (0x555be568bb88)
- instruction: $q0 = MOVID 0
- operand 0:   $q0
$q0 is not a FPR64 register.
...

see more details here https://lab.llvm.org/buildbot/#/builders/104/builds/7797/steps/6/logs/FAIL__LLVM__zero-call-used-regs_ll

the FAIL: llvm-libunwind-static.cfg.in:: aarch64.ra_sign_state.pass.cpp test is getting failed on Linux Ubuntu/Aarch64 toolchain builders with the following output:

@dgg5503, I did one more rebuild and this time the result completely different. In comparison with the previous build, where libcxx ci and windows tests have failed, this time all those tests have passed, but the debian target tests have failed. I suppose, because these changes touch the common cmake configuration file, it triggers all possible cases/targets for the builds and not all of these tests are work correctly in that time.
So, the changes are not related with these failed tests. I'll commit your changes.

Thank you @paulkirth. I have tested these changes locally on the builder. It works fine.

Hi @dgg5503, thank you, LGTM, but the pre-build status is failed. I don't see that failing of those tests are related with these changes. Anyway, would you double check it just in case?

using of specific triple within stack-usage-safestack.c test causes a failure for the compilers, which don't support these triples (arm/aarch64 in my case).
Such as:

error: unable to create target: 'No available targets are compatible with triple "i386-apple-darwin"'

see more details in https://lab.llvm.org/buildbot/#/builders/119/builds/8169/steps/9/logs/FAIL__Clang__stack-usage-safestack_c result for the failed build.

@ldionne, would you take a look? I would like to restart our ARMv7 win-to-linux cross builder with these new configuration files, but they don't work with the remote test execution properly.

thank you a lot! The armv7/aarch64 cross win-x-linux release builders are green now:

• https://lab.llvm.org/buildbot/#/builders/144/builds/238
• https://lab.llvm.org/buildbot/#/builders/143/builds/262

I found that the release/14.x branch has missed at least the following commits for clang/cmake/caches/CrossWinToARMLinux.cmake file:

thank you a lot to pointing at the problems. Looks like armv7 builder gets failed because of some missed commits. aarch64 looks very strange, but also possible that there is the same reason.
I'm investigating the problems.

@gkistanova I would like to connect those workers/builders to the staging master at first and switch to the production master later.

I'm testing https://reviews.llvm.org/D119918 locally on the builders. Looks like TARGET_TRIPLE as a cache file parameter slightly affects the configuration. I'm getting the warnings during the initial configuration.
I'll replace the parameter name to TOOLCHAIN_TARGET_TRIPLE to avoid the possible future mistakes and just in case.

no need those changes for CrossWinToARMLinux.cmake. TARGET_TRIPLE is using to parametrize the cache file only.
But if there is a goal to completely remove TARGET_TRIPLE from the source tree I will update the cache file and the buildbot configuration accordingly

I was planning on landing https://reviews.llvm.org/D119918 which renames TARGET_TRIPLE in CrossWinToARMLinux.cmake, would that address the issue?

Those builders are currently on staging buildbot.

the TARGET_TRIPLE is a parameter for the CrossWinToARMLinux.cmake cache file and used within it to configure the build, including LLVM_DEFAULT_TARGET_TRIPLE. Your changes will break the Win-to-Linux cross toolchain builds.
Would you revert your commit?

@vvereschaka @broadwaylamb clang/cmake/caches/CrossWinToARMLinux.cmake is using those variables -- we should try to use the native CMake equivalents instead.

@ldionne , thank you. 'll update CrossWinToARMLinux.cmake accordingly.

@ldionne

@vvereschaka Actually, I think it's adding a space after -isystem that broke your Windows build.

yes, that's it. Thank you, it is fixed now.

The libc++::in_out_result.pass.cpp test gets failed to build with the following error:

Updated with revision id 6911944e3a24864c6560733310c1047af9a9f5a6

Do we need to apply attribute((noinline)) to main? Can you try that out and let me know if that helps?

I ran these changes on Linux (Ubuntu 18.04)/Aarch64 board. The test gets failed because of missed 'main':

ubuntu@jetson8:/tmp$ ./t.tmp.exe 
info.dli_sname: _Z14signal_handleri
info.dli_sname: __kernel_rt_sigreturn
info.dli_sname: _Z18crashing_leaf_funcv
info.dli_sname: __libc_start_main

Hi @danielkiss,
The buildbot's build is broken already for more than one day without attention. Sorry, but I'm going to revert this commit.

understood, thank you!
I'll take a closer look at these warnings to figure out the source.

looks like these changes are reason of bunch of build warnings on the windows builders (VC). I see more than 1000 additional warnings such as

C:\buildbot\as-builder-1\x-armv7l\llvm-project\llvm\include\llvm/ADT/Sequence.h(119): warning C4309: 'static_cast': truncation of constant value
C:\buildbot\as-builder-1\x-armv7l\llvm-project\llvm\include\llvm/ADT/Sequence.h(120): warning C4309: 'static_cast': truncation of constant value
C:\buildbot\as-builder-1\x-armv7l\llvm-project\llvm\include\llvm/ADT/Sequence.h(119): warning C4309: 'static_cast': truncation of constant value
C:\buildbot\as-builder-1\x-armv7l\llvm-project\llvm\include\llvm/ADT/Sequence.h(120): warning C4309: 'static_cast': truncation of constant value

same as for @thakis, these changes have broken the armv7 toolchain builder

11.219 [3/3/902] Linking CXX shared library C:\buildbot\as-builder-1\x-armv7l\build\lib\armv7-unknown-linux-gnueabihf\libc++abi.so.1.0
FAILED: C:/buildbot/as-builder-1/x-armv7l/build/lib/armv7-unknown-linux-gnueabihf/libc++abi.so.1.0 
cmd.exe /C "cd . && C:\buildbot\as-builder-1\x-armv7l\build\.\bin\clang++.exe --target=armv7-unknown-linux-gnueabihf -fPIC -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 -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 --target=armv7-unknown-linux-gnueabihf --sysroot=C:/buildbot/.arm-ubuntu  -O3 -DNDEBUG  -Wl,-z,nodelete -Wl,--color-diagnostics  --target=armv7-unknown-linux-gnueabihf --sysroot=C:/buildbot/.arm-ubuntu -nostdlib++ -shared -Wl,-soname,libc++abi.so.1 -o C:\buildbot\as-builder-1\x-armv7l\build\lib\armv7-unknown-linux-gnueabihf\libc++abi.so.1.0 libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_aux_runtime.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_default_handlers.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_demangle.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_exception_storage.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_guard.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_handlers.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_vector.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_virtual.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/stdlib_exception.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/stdlib_stdexcept.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/stdlib_typeinfo.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/abort_message.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/fallback_malloc.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/private_typeinfo.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_exception.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_personality.cpp.o libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_thread_atexit.cpp.o  -Wl,-rpath,$ORIGIN/../lib  C:/buildbot/as-builder-1/x-armv7l/build/lib/clang/14.0.0/lib/armv7-unknown-linux-gnueabihf/libclang_rt.builtins.a  C:/buildbot/as-builder-1/x-armv7l/build/lib/armv7-unknown-linux-gnueabihf/libunwind.a  -lpthread  -lc  C:/buildbot/as-builder-1/x-armv7l/build/lib/clang/14.0.0/lib/armv7-unknown-linux-gnueabihf/libclang_rt.builtins.a  -ldl  -lpthread && cd ."
ld.lld: error: relocation R_ARM_ABS32 cannot be used against symbol '_Unwind_Resume'; recompile with -fPIC
>>> defined in C:/buildbot/as-builder-1/x-armv7l/build/lib/armv7-unknown-linux-gnueabihf/libunwind.a(Unwind-EHABI.cpp.o)
>>> referenced by cxa_exception.cpp
>>>               libcxxabi/src/CMakeFiles/cxxabi_shared.dir/cxa_exception.cpp.o:(.text.__cxa_end_cleanup+0x18)
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

these changes break the remote test execution on the cross toolchain builders. The libunwind tests get running on the local host instead of the remote target.
https://lab.llvm.org/buildbot/#/builders/60/builds/5235

Would it make sense for that to be a full triple instead of just the result of sys.platform?

Now I got it, thank you. I have prepared proper changes here https://reviews.llvm.org/D105369

I did some research and I found that lld project does not contain any expensive checks. There is nothing to run on the expensive check builders.
But there is few builders that run the lld tests including MachO/stabs.s. As example lld-x86_64-ubuntu-fast - https://lab.llvm.org/buildbot/#/builders/58

@vvereschaka, could we run lld tests on that bot too? lld tests run pretty quickly.

we've started getting the warnings for newly created file llvm/lib/Transforms/Utils/MemoryOpRemark.cpp on the cross toolchain builders:

Thank you @aeubanks, got it.

these changes breaks the new-pm-lto-defaults.ll test on the cross win-x-arm linux cross builders:

• https://lab.llvm.org/buildbot/#/builders/119/builds/3775/steps/8/logs/FAIL__LLVM__new-pm-lto-defaults_ll
• https://lab.llvm.org/buildbot/#/builders/60/builds/3287/steps/8/logs/FAIL__LLVM__new-pm-lto-defaults_ll

got it, perfect. Thank you.

@ldionne, @curdeius thank you for review.
Updated diff accordingly

• reworded comment
• %t.grep => %t.escaped.grep
• do not remove temporary file in the test.