Bug 99048 - __gcc_qadd produces spurious NaN
Summary: __gcc_qadd produces spurious NaN
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 10.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-09 23:33 UTC by Benjamin Barenblat
Modified: 2021-02-12 17:02 UTC (History)
2 users (show)

See Also:
Host:
Target: powerpc64le-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-02-12 00:00:00


Attachments
minimal example (150 bytes, text/plain)
2021-02-09 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 2021-02-09 23:33:36 UTC
Created attachment 50160 [details]
minimal example

__gcc_qadd, which adds two long doubles on POWER, can emit NaN for non-NaN input:

	$ cat ldbl.c
	extern int printf(const char* restrict, ...);
	int main() {
		long double a = -0x1.1e282e024debdb875f47f6c85p+1021L;
		printf("%Le\n", a + 0x1.fffffffffffff7ffffffffffff8p+1023L);
	}
	$ gcc -O0 -o ldbl ldbl.c
	$ ./ldbl
	nan
	$ gcc -O1 -o ldbl ldbl.c
	$ ./ldbl
	1.546510e+308

Examining the assembly from the second invocation shows that GCC has optimized out the entire computation. In the first invocation, however, the compiled program calls __gcc_qadd, which yields NaN. By IEEE 754, adding two non-NaN inputs should never produce a NaN output.

Output of 'gcc -v':
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --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=powerpc64le-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-offload-targets=nvptx-none=/build/gcc-10-jGDcMs/gcc-10-10.2.1/debian/tmp-nvptx/usr --without-cuda-driver --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Comment 1 Segher Boessenkool 2021-02-12 16:26:30 UTC
IBM long double ("double-double") is not an IEEE floating point format,
so all these rules do not apply, but you are right it is surprising.
Comment 2 Jakub Jelinek 2021-02-12 16:54:55 UTC
a = -2.5118280672773279e+307
c = 1.7976931348623157e+308
c is in particular the maximum normalized number, __DBL_MAX__, binary 0x7fefffffffffffff.
126	  z = a + c;
z = 1.546510328134583e+308

and that is finite.

144	      q = a - z;

But this is -inf.
145	      zz = q + c + (a - (q + z)) + aa + cc;
and everything goes downhill from there, as a, c, z, aa and cc are all finite,
but q is -inf and a - (-inf + finite) is +inf and -inf + +inf is nan.

So, the code:
  z = a + c;

  if (nonfinite (z))
    {
...
    }
  else
    {
      q = a - z;
would need another if (nonfinite (q)) check after computation of q (and I don't believe it could just compute q = a - z; right after z = a + c; and replace if (nonfinite (z)) with if (nonfinite (q)) because if a is +-inf and c is finite, z will be +-inf and q will be nan.
Comment 3 Segher Boessenkool 2021-02-12 17:02:53 UTC
Yup, something like that.  It should not have any infinities here afaics.