Created attachment 49749 [details] preprocessed minimal example On 32-bit ARM without hardware floating point, libgcc narrows a negative NaN double to a positive NaN float. However, GCC's optimizer assumes that narrowing conversions preserve sign even in the presence of NaN: $ cat float.c #include <math.h> extern int printf(const char* format, ...); static const char* pm(double d) { return signbit(d) ? "-" : "+"; } int main(void) { double d = copysign(nan(""), -1.0); float f = d; printf("d is %sNaN; f is %sNaN\n", pm(d), pm(f)); } $ gcc -O0 -o float float.c -lm $ ./float d is -NaN; f is +NaN $ gcc -O1 -o float float.c -lm $ ./float d is -NaN; f is -NaN Examining the assembly from the second invocation shows that GCC has optimized out the entire computation. In the first invocation, however, the compiled calls into libgcc, and libgcc/config/arm/ieee754-df.S:1475 always narrows NaNs to +NaN: 3: @ chech for NAN mvns r3, r2, asr #21 bne 5f @ simple overflow orrs r3, xl, xh, lsl #12 do_it ne, tt movne r0, #0x7f000000 orrne r0, r0, #0x00c00000 RETc(ne) @ return NAN I've attached the preprocessed version of float.c. Output of 'gcc -v': Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/10/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=arm-linux-gnueabi- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv5te --with-float=soft --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20201207 (Debian 10.2.1-1)
i believe ieee-754 only specifies the sign bit of a nan after copy, negate, abs and copysign operations. iso c does not specify further requirements about the sign bit of a nan either. so i think gcc should not assume that conversions preserve the sign bit. (there may be real hw where that is not the case, independently from what libgcc is doing.)