Bug 98251 - libgcc on 32-bit soft-float ARM narrows -NaN incorrectly
Summary: libgcc on 32-bit soft-float ARM narrows -NaN incorrectly
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcc (show other bugs)
Version: 10.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-11 23:33 UTC by Benjamin Barenblat
Modified: 2021-01-04 14:16 UTC (History)
1 user (show)

See Also:
Host:
Target: arm
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
preprocessed minimal example (3.75 KB, text/plain)
2020-12-11 23:33 UTC, Benjamin Barenblat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Barenblat 2020-12-11 23:33:29 UTC
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)
Comment 1 nsz 2020-12-17 17:40:34 UTC
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.)