llvm-project.git/libc/src/complex, branch main

[libc] Don't manually override the optimization level for math (#126322)

2025-02-11T07:56:47+00:00

This was originally done for testing purposes, but after #126315 we now
do testing through GitHub Actions and should be instead using the
optimization setting chosen by the user.

[libc][complex] Testing infra for MPC (#121261)

2025-01-28T05:31:16+00:00

This PR aims to add the groundwork to test the precision of libc complex
functions against MPC. I took `cargf` as a test to verify that the infra
works fine.

[libc][complex] add cfloat16 and cfloat128 compiler flags (#121140)

2024-12-26T07:20:07+00:00

Proper fix for the temporary fix in #114696

[libc][complex] Implement different flavors of the `cproj` function (#119722)

2024-12-17T20:34:50+00:00

Refer section 7.3.9.5 of ISO/IEC 9899:2023

[libc][complex] Implement different flavors of the `conj` function (#118671)

2024-12-10T04:35:11+00:00

Refer section 7.3.9.4 of ISO/IEC 9899:2023

[libc] suppress more clang-cl warnings (#117718)

2024-11-26T20:15:58+00:00

- migrate more `-O3` to `${libc_opt_high_flag}`
- workaround a issue with `LLP64` in test. The overflow testing is
guarded by a constexpr but the literal overflow itself will still
trigger warnings.

Notice that for math smoke test, for some reasons, the
`${libc_opt_high_flag}` will be passed into `lld-link` which confuses
the linker so there are still some warnings leftover there. I can
investigate more when I have time.

[libc][complex] implement different flavors of `creal` and `cimag` functions (#113300)

2024-11-03T04:08:09+00:00

I have commented out the test for `neg_zero`(creal) because : 

1. real(neg_zero + 0.0i) equals zero. 
2. real(neg_zero - 0.0i) equals neg_zero.

I am not sure if this is the intended behaviour. 

[EDIT]
I have updated tests for `neg_zero` (creal) to be : 

```
    EXPECT_FP_EQ(func(CFPT(neg_zero - zero * 1.0i)), neg_zero);
    EXPECT_FP_EQ(func(CFPT(neg_zero + zero * 1.0i)), zero);
```

because all three [gcc, clang and GNU MPC] also give the same result. 
https://godbolt.org/z/hxhcn6aof
and it seems that it is indeed the correct behaviour since Imaginary
types are not supported yet, refer #113671