[Bug libgcc/98251] New: libgcc on 32-bit soft-float ARM narrows -NaN incorrectly

[Bug libgcc/98251] New: libgcc on 32-bit soft-float ARM narrows -NaN incorrectly

[bbarenblat at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98251

            Bug ID: 98251
           Summary: libgcc on 32-bit soft-float ARM narrows -NaN
                    incorrectly
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bbarenblat at gmail dot com
  Target Milestone: ---

Created attachment 49749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49749&action=edit
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)

[Bug libgcc/98251] libgcc on 32-bit soft-float ARM narrows -NaN incorrectly

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98251

nsz at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nsz at gcc dot gnu.org

--- Comment #1 from nsz at gcc dot gnu.org ---
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.)