[libc] check-libc fails at LlvmLibcDyadicFloatTest.EdgeRangesLongDouble test

[amemov]

I'm trying to build and run the libc on my machine using WSL (Ubuntu 24.04.1 LTS) on i7-9700K CPU.
For building the project, I use the same cmake command provided on the Libc's website:

cmake ../runtimes -G Ninja -DLLVM_ENABLE_RUNTIMES="libc"  \
   -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ \
   -DCMAKE_BUILD_TYPE=Release 

Below is the error message that ninja check-libc outputs:
error_msg.txt

[llvmbot]

@llvm/issue-subscribers-libc

Author: Anton (amemov)

I'm trying to build and run the libc on my machine using WSL (Ubuntu 24.04.1 LTS) on i7-9700K CPU. For building the project, I use the same cmake command provided on the [Libc's website](https://libc.llvm.org/overlay_mode.html#overlay-mode): ``` cmake ../runtimes -G Ninja -DLLVM_ENABLE_RUNTIMES="libc" \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release ``` Below is the error message that `ninja check-libc `outputs: [error_msg.txt](https://github.com/user-attachments/files/19948309/error_msg.txt)

[amemov]

@lntue

[amemov]

@lntue , so I decided to do some more tweaking to see what the problem actually was. The error that is in the text file above - it was generated by WSL version 1.

I decided to install WSL version 2 patch, and now it doesn't fail this test, but instead it gets a segmentation fault when you get to this test:

cd llvm-project/build/libc/test/src/__support/time/linux
./libc.test.src.__support.time.linux.timeout_test.__unit__.__build__

Result:

[==========] Running 5 tests from 1 test suite.
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.NegativeSecond
[       OK ] LlvmLibcSupportLinuxTimeoutTest.NegativeSecond (1 us)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.OverflowNano
[       OK ] LlvmLibcSupportLinuxTimeoutTest.OverflowNano (1 us)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.UnderflowNano
[       OK ] LlvmLibcSupportLinuxTimeoutTest.UnderflowNano (0 ns)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.NoChangeIfClockIsMonotonic
[       OK ] LlvmLibcSupportLinuxTimeoutTest.NoChangeIfClockIsMonotonic (1 us)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.ValidAfterConversion
Segmentation fault

---

I re-ran the LlvmLibcDyadicFloatTests that were previously failing and in WSL 2 they are working correctly

[lntue]

I installed WSL Ubuntu 24 and I cannot reproduce both errors you got. Instead, I got a different build error from libc.test.src.math.smoke.hypotf16_test.__unit__, which looks like some optimization issues from clang. This is my WSL version:

> wsl --version
WSL version: 2.4.13.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5716
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.3775

and I tried with both clang-18 and clang-19 from the WSL Ubuntu installation.

[amemov]

Checked my WSL version and everything is the same with the exception of Windows version:

> wsl --version
WSL version: 2.4.13.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5716
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.19045.5737

What I haven't checked is trying to build the project with different versions of Clang. I will look into that later, but before that, I will check what exactly is causing the Segmentation fault in one of the tests that I mentioned in my last message above

Upd: checked different clang versions 17.0.0 and 18.1.3 - same segmentation fault error in the same test

[amemov]

Ok, so I rebuilt the project once again (Clang 18.1.3), and ran the ./libc.test.src.__support.time.linux.timeout_test.__unit__.__build__ test through LLDB and I got this backtrace:

(lldb) target create "./libc.test.src.__support.time.linux.timeout_test.__unit__.__build__"
Current executable set to '/mnt/d/LLVMStuff/llvm-project/build/libc/test/src/__support/time/linux/libc.test.src.__support.time.linux.timeout_test.__unit__.__build__' (x86_64).
(lldb) run
Process 527806 launched: '/mnt/d/LLVMStuff/llvm-project/build/libc/test/src/__support/time/linux/libc.test.src.__support.time.linux.timeout_test.__unit__.__build__' (x86_64)
[==========] Running 5 tests from 1 test suite.
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.NegativeSecond
[       OK ] LlvmLibcSupportLinuxTimeoutTest.NegativeSecond (2 us)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.OverflowNano
[       OK ] LlvmLibcSupportLinuxTimeoutTest.OverflowNano (1 us)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.UnderflowNano
[       OK ] LlvmLibcSupportLinuxTimeoutTest.UnderflowNano (1 us)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.NoChangeIfClockIsMonotonic
[       OK ] LlvmLibcSupportLinuxTimeoutTest.NoChangeIfClockIsMonotonic (1 us)
[ RUN      ] LlvmLibcSupportLinuxTimeoutTest.ValidAfterConversion
Process 527806 stopped
* thread #1, name = 'libc.test.src._', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000555555555a75 libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`__llvm_libc_21_0_0_git::getauxval(unsigned long) + 53
libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`__llvm_libc_21_0_0_git::getauxval:
->  0x555555555a75 <+53>: movq   (%rcx), %rdx
    0x555555555a78 <+56>: movl   $0x2, %esi
    0x555555555a7d <+61>: testq  %rdx, %rdx
    0x555555555a80 <+64>: je     0x555555555b06 ; <+198>
Target 0: (libc.test.src.__support.time.linux.timeout_test.__unit__.__build__) stopped.
(lldb) thread backtrace
* thread #1, name = 'libc.test.src._', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x0000555555555a75 libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`__llvm_libc_21_0_0_git::getauxval(unsigned long) + 53
    frame #1: 0x0000555555555e10 libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`__llvm_libc_21_0_0_git::vdso::Symbol::initialize_vdso_global_cache() + 80
    frame #2: 0x000055555555579d libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`__llvm_libc_21_0_0_git::callonce_impl::callonce_slowpath(__llvm_libc_21_0_0_git::Futex*, void (*)()) + 29
    frame #3: 0x000055555555625b libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`__llvm_libc_21_0_0_git::internal::clock_gettime(int, timespec*) + 43  
    frame #4: 0x0000555555555428 libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`LlvmLibcSupportLinuxTimeoutTest_ValidAfterConversion::Run() + 24      
    frame #5: 0x00005555555667ab libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`__llvm_libc_21_0_0_git::testing::Test::runTests(__llvm_libc_21_0_0_git::testing::TestOptions const&) + 603
    frame #6: 0x000055555556c0a7 libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`main + 599
    frame #7: 0x00007ffff7a391ca libc.so.6`___lldb_unnamed_symbol3278 + 122
    frame #8: 0x00007ffff7a3928b libc.so.6`__libc_start_main + 139
    frame #9: 0x0000555555555075 libc.test.src.__support.time.linux.timeout_test.__unit__.__build__`_start + 37

Judging by the backtrace, I don't think it's Clang's fault. I think the problem might lie in the file below, but don't quote me on that. I will try to look into that more in-depth sometime this week.

llvm-project/libc/src/sys/auxv/linux/getauxval.cpp

Line 176 in 74f55c7

LLVM_LIBC_FUNCTION(unsigned long, getauxval, (unsigned long id)) {

[amemov]

@lntue , I decided to rebuild the project 1 more time with -DCMAKE_BUILD_TYPE=Debug - and it worked up until my test file that I'm working on, and it no longer fails on the test that I mentioned before (which appears much much earlier before my test case ) . Then I rebuilt it -DCMAKE_BUILD_TYPE=Release - same thing, no more segmentation fault. I'm a little confused right now - was it because I copied the build command somehow incorrectly ( or something else? )

Anyways, I also decided to run the test that you mentioned above, and it fails for me as well in my WSL with
-DCMAKE_BUILD_TYPE=Release.

upd: with -DCMAKE_BUILD_TYPE=Debug the libc.test.src.math.smoke.hypotf16_test.__unit__ works fine for me