math: nan-related signops vary with C compiler.

[Luyten-Orion]

Specification

In the C backend, signops on NaN are dependent on the C compiler used. My compiler is Clang 20.1.8, for reference.

Example

doAssert not signbit(NaN)

Actual Output

An assertion defect.

Expected Output

No output.

Possible Solution

A fix would be to always ensure that Nimskull's NaN is a positive NaN, though I'm not sure on how to do this.

Additional Information

I did try to see if a pure implementation of these ops would work, but it seems that the issue is with how NaN is defined rather than the function implementation.

References

[zerbina]

Thanks for filing an issue.

What platform did you test this on? More specifically what platform was/is the C compiler targeting? I tried with Clang 20.1.0 on Windows, compiling for x86_64-windows-gnu, but I'm unable to reproduce the assertion failing, both when using debug as well as when using release mode.

Further, I've looked at the output of both clang and gcc (for various architectures), and in none that I looked "negative" NANs (sign bit set to 1) are used, nor do they return true for signbit(NAN) (Godbolt).

[Luyten-Orion]

Here's the full output of gcc -v (the compiler I'm using for Skull currently):

chronos@ChronosPC ~/test> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/15.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.2.1 20250813 (GCC) 

I'm running this on Linux, amd64. My specific CPU is AMD Ryzen 7 5800X, if that matters. You can look at the logs here of the GH Action that tested my WIP PR: https://github.com/nim-works/nimskull/actions/runs/18087111367/job/51460319706?pr=1622#step:6:1638

[Luyten-Orion]

The reason for this issue was found. Zerbina discovered that glibc has added a check to only declare NAN if it was not already defined, meaning the implementation in nimbase.h was used, defaulting to a negative NaN on my platform. See commit: https://sourceware.org/git/?p=glibc.git;a=commit;h=bdc7f4b4e25f49b4e25578d98d58b113d0e961f1