Before:
* test-zigc: run libzigc unit tests (part of test-modules)
* test-libc: run libc-test cases
Now:
* test-libc: run libc API unit tests (part of test-modules)
* test-libc-nsz: run libc-test cases
libc API unit tests (previously referred to as libzigc unit tests) now run for
all supported targets, even those we don't provide libzigc for. The idea is that
this will help us catch bad assumptions in the unit tests, as well as bugs in
other libcs.
I considered this setup:
* test-c: run libc API unit tests (part of test-modules)
* test-libc-nsz: run libc-test cases
* test-libc: both of the above
However, I do not like it because it gives a false sense of security; the full
module and C ABI test suites are still liable to catch libzigc bugs that test-c
and test-libc-nsz might not. So contributors should just run the test steps
outlined in https://codeberg.org/ziglang/zig/issues/30978.
Co-authored-by: rpkak <rpkak@noreply.codeberg.org>
For some of these functions and most targets this changes nothing,
either because long double and double are not equivalent or because
llvm did function deduplication.
But e.g. on aarch64-windows-gnu, ucrt provides hypot, but not hypotl.
Now hypotl calls hypot from ucrt instead of including the std.math.hypot
implementation in zigc.
Very trivial functions (like nanl) are not changed, because a function call would probably make this function more complex.
mingw,musl,wasi-libc: remove c files, that only provide functions already included in zigc
mingw: remove c files, that only provide functions, which are in ucrt
mingw: do not include mingw files/zigc functions on targets on which they in ucrt
Seems like it was missed when implementing `rint`.
This was checked by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=rint -fqemu -fwasmtime --summary line
Build Summary: 2209/2209 steps succeeded
```
The implementation was ported from `musl` to Zig code, and the `rint`
unit tests were generalized so they could be used for `rintf` as well.
This was checked both through unit tests and running `libc-test` suite:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=rintf -fqemu -fwasmtime --summary line
Build Summary: 1657/1657 steps succeeded
```
The behaviour of `libc` `finite` functions is the same as Zig std's, so
the function basically delegates to `math.isFinite` and no new tests were
added. These functions are obsolete, but still part of `musl`.
No results are attached in this case as `libc-test` doesn't have tests for them.
The `frexp` implementation was generalized so it can be used for `f32`
and `c_longdouble` types as well.
The changes were tested by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=frexp -fqemu -fwasmtime --summary line
Build Summary: 737/737 steps succeeded
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=frexpf -fqemu -fwasmtime --summary line
Build Summary: 369/369 steps succeeded
```
The changes were tested by running:
```
$ ./build/stage3/bin/zig build -p stage4 -Denable-llvm -Dno-lib
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=frexp -fqemu -fwasmtime --summary line
Build Summary: 737/737 steps succeeded
```
The tests were passing even when it was a straightforward calling of Zig
std library, but I wanted the `x is NaN` special case to match the
behaviour described in `libc` manpages, and for it to be consistent
with how infinities as arguments are handled in Zig.
`modf` function was generalized and renamed to `modfGeneric`, `modf` and
`modff` provide the appropriate type while calling that function. The
unit tests were also generalized so they can be reused for different
float types.
Both `modf` and `modff` were tested after making these changes:
```
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=modf -fqemu -fwasmtime --summary line
Build Summary: 921/921 steps succeeded
```
```
stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=modff -fqemu -fwasmtime --summary line
Build Summary: 369/369 steps succeeded
```
The behaviour regarding special cases differs between `libc` and Zig's
`stdlib` for `modf`, so the implementation couldn't be a straightforward
calling of `stdlib` function.
Other than the obvious documented differences, I also had problems with
the `INVALID` flag being raised while running `libc-test` suite on riscv
arch through qemu. The solution was to test if the argument is `NaN`,
and then return a quiet `NaN` if so.
Passing tests, that should include all the special cases to be wary of,
were also added.
Test results:
```
$ stage4/bin/zig build test-libc -Dlibc-test-path=<LIBC-TEST-PATH> -Dtest-filter=modf -fqemu -fwasmtime --summary line
Build Summary: 921/921 steps succeeded
```
The functions were sorted alphabetically for easier navigation, and less
confusion where to add a new one. The sorting of comptime exports was
done within the visual "blocks".
Since this is my first time contributing I wanted to keep it simple and I added just one function
I tested with
```bash
stage3/bin/zig build -p stage4 -Dno-lib -Dno-langref -Denable-llvm=true --search-prefix ~/repos/zig-boostrap/out/native-linux-musl-baseline/
stage4/bin/zig build test-libc -Dlibc-test-path=../libc-test -Dtest-target-filter=x86_64-linux-musl
```
and the tests passed.
I'm planning on doing more once I get the hang of it.
Co-authored-by: david <davidc.fried@gmail.com>
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/30888
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
Co-authored-by: Daggerfall-is-the-best-TES-game <daggerfall-is-the-best-tes-game@noreply.codeberg.org>
Co-committed-by: Daggerfall-is-the-best-TES-game <daggerfall-is-the-best-tes-game@noreply.codeberg.org>
Alex Rønne Petersen