New signaling NaN causes 12 testsuite failures

New signaling NaN causes 12 testsuite failures

[Steve Kargl]

% gmake check-fortran  RUNTESTFLAGS="ieee.exp=sign\*"

Test run by sgk on Mon Jan 24 16:42:07 2022
Native configuration is x86_64-unknown-freebsd14.0

                === gfortran tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/home/sgk/gcc/gccx/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/ieee/ieee.exp ...
FAIL: gfortran.dg/ieee/signaling_1.f90   -O0  execution test
FAIL: gfortran.dg/ieee/signaling_1.f90   -O1  execution test
FAIL: gfortran.dg/ieee/signaling_1.f90   -O2  execution test
FAIL: gfortran.dg/ieee/signaling_1.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/signaling_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/signaling_1.f90   -Os  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O0  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O1  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O2  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/signaling_3.f90   -Os  execution test

                === gfortran Summary ===

# of expected passes            12
# of unexpected failures        12
# of unsupported tests          6
/usr/home/sgk/gcc/objx/gcc/gfortran  version 12.0.1 20220124 (experimental) (GCC) 

-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Mon, Jan 24, 2022 at 04:44:53PM -0800, Steve Kargl wrote:
> % gmake check-fortran  RUNTESTFLAGS="ieee.exp=sign\*"
> 

Line 42 of signal_1.f90 looks wrong unless the
line is testing conversion on assignment.  Should
y be x?

Instrumented signal_1.f90.

Changed

    if (ieee_class(z) /= ieee_signaling_nan) stop 300

to

    if (ieee_class(z) /= ieee_signaling_nan) then
        print '(G0,1X,Z0)', z, z
        z = ieee_value(z, ieee_quiet_nan)
        print '(G0,1X,Z0)', z, z
        z = ieee_value(z, ieee_signaling_nan)
        print '(G0,1X,Z0)', z, z
!       stop 300
    end if


Got the following in testsuite/gfortran/gfortran.log

NaN 7FFFA000000000000000
NaN 7FFFC000000000000000
NaN 7FFFA000000000000000

and with "stop 300" commented out everything passes.  Now to
chase down hex representations for sNaN and qNaN.  Suspect
ieee_class() is broken.
-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[FX]

Hi Steve,

> New signaling NaN causes 12 testsuite failures

Thanks for alerting me.


> Line 42 of signal_1.f90 looks wrong unless the
> line is testing conversion on assignment.  Should
> y be x?

Indeed. Fixed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c0a4a658097c56fa03d04b8d15c3ea02961d62a4


> Got the following in testsuite/gfortran/gfortran.log
> 
> NaN 7FFFA000000000000000
> NaN 7FFFC000000000000000
> NaN 7FFFA000000000000000
> 
> and with "stop 300" commented out everything passes.  Now to
> chase down hex representations for sNaN and qNaN.  Suspect
> ieee_class() is broken.

How does the long double formation look like on x86_64-unknown-freebsd?
That test passes on x86_64 for linux and darwin, so I’m wondering what’s different about freebsd…

Can you tell me whether the C front-end defines __LDBL_IS_IEC_60559__? What is the value of __LDBL_DIG__? __DBL_DIG__? __FLOAT_WORD_ORDER == __BIG_ENDIAN or __LITTLE_ENDIAN?


FX

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 09:05:55AM +0100, FX wrote:
> Hi Steve,
> 
> > New signaling NaN causes 12 testsuite failures
> 
> Thanks for alerting me.
> 
> > Line 42 of signal_1.f90 looks wrong unless the
> > line is testing conversion on assignment.  Should
> > y be x?
> 
> Indeed. Fixed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c0a4a658097c56fa03d04b8d15c3ea02961d62a4
> 

Thanks.

> > Got the following in testsuite/gfortran/gfortran.log
> > 
> > NaN 7FFFA000000000000000
> > NaN 7FFFC000000000000000
> > NaN 7FFFA000000000000000
> > 
> > and with "stop 300" commented out everything passes.  Now to
> > chase down hex representations for sNaN and qNaN.  Suspect
> > ieee_class() is broken.
> 
> How does the long double formation look like on x86_64-unknown-freebsd?

Ugh.  I'm afraid that this might be a mess.

> That test passes on x86_64 for linux and darwin, so I’m wondering
> what’s different about freebsd…
> 
> Can you tell me whether the C front-end defines __LDBL_IS_IEC_60559__?
> What is the value of __LDBL_DIG__? __DBL_DIG__?
> __FLOAT_WORD_ORDER == __BIG_ENDIAN or __LITTLE_ENDIAN?
> 

% cat a.c
#include <stdio.h>
int
main(void)
{
#ifdef __LDBL_IS_IEC_60559__
   printf("__LDBL_IS_IEC_60559__?  yes\n");
#else
   printf("__LDBL_IS_IEC_60559__?  no\n");
#endif
   return 0;
};

% gcc11 -o z a.c && ./z            <-- initial bootstrap compiler
__LDBL_IS_IEC_60559__?  yes
% cc -o z a.c && ./z               <-- clang/llvm FreeBSD system compiler
__LDBL_IS_IEC_60559__?  no
% ~/work/x/bin/gcc -o z a.c && ./z <-- gcc build from origin/master
__LDBL_IS_IEC_60559__?  yes

There might be some strange interaction between FreeBSD native
toolchain binaries and the binaries I build duringi bootstrap.

The LDBL info from /usr/include/x86/float is

#define LDBL_MANT_DIG   64
#define LDBL_EPSILON    1.0842021724855044340E-19L
#define LDBL_DIG        18
#define LDBL_MIN_EXP    (-16381)
#define LDBL_MIN        3.3621031431120935063E-4932L
#define LDBL_MIN_10_EXP (-4931)
#define LDBL_MAX_EXP    16384
#define LDBL_MAX        1.1897314953572317650E+4932L
#define LDBL_MAX_10_EXP 4932
#if __ISO_C_VISIBLE >= 2011
#define LDBL_TRUE_MIN   3.6451995318824746025E-4951L
#define LDBL_DECIMAL_DIG 21
#define LDBL_HAS_SUBNORM 1
#endif /* __ISO_C_VISIBLE >= 2011 */

which is what I expect.  How this maps to the __LDBL_DIG__
info, I do not know.

% grep -R __LDBL_DIG__ /usr/include
/usr/include/c++/v1/limits:    static _LIBCPP_CONSTEXPR const int  digits10 = __LDBL_DIG__;

%  grep -R __FLOAT_WORD_ORDER /usr/include

Returns no hits, but I see

% grep -R __BIG_ENDIAN /usr/include
/usr/include/c++/v1/__config:#ifdef __BIG_ENDIAN__
/usr/include/c++/v1/__config:#  if __BIG_ENDIAN__
/usr/include/c++/v1/__config:#  endif  // __BIG_ENDIAN__
/usr/include/c++/v1/__config:#endif // __BIG_ENDIAN__
/usr/include/c++/v1/__config:#  elif __BYTE_ORDER == __BIG_ENDIAN
/usr/include/c++/v1/__config:#  else  // __BYTE_ORDER == __BIG_ENDIAN

So, maybe __BYTE_ORDER instead of  __FLOAT_WORD_ORDER?

-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 09:05:55AM +0100, FX wrote:
> 
> > Got the following in testsuite/gfortran/gfortran.log
> > 
> > NaN 7FFFA000000000000000
> > NaN 7FFFC000000000000000
> > NaN 7FFFA000000000000000
> > 

Could be a problem with __builtin_nansl().

#include <stdio.h>
#include <stdint.h>

int
main(void)
{
   union {       float x; uint32_t i; }    f;
   union {      double x; uint64_t i; }    d;
   union { long double x; uint64_t i[2]; } l;

   printf("Quiet NaN\n");
   f.x = __builtin_nanf("");
   printf("%f %x\n", f.x, f.i);
   d.x = __builtin_nan("");
   printf("%lf %lx\n", d.x, d.i);
   l.x = __builtin_nanl("");
   printf("%Lf %lx%lx\n", l.x, l.i[1], l.i[0]);

   printf("Signaling NaN\n");
   f.x = __builtin_nansf("");
   printf("%f %x\n", f.x, f.i);
   d.x = __builtin_nans("");
   printf("%lf %lx\n", d.x, d.i);
   l.x = __builtin_nansl("");
   printf("%Lf %lx%lx\n", l.x, l.i[1], l.i[0]);

   return 0;
} 

% ~/work/x/bin/gcc -o z a.c && ./z
Quiet NaN
nan 7fc00000
nan 7ff8000000000000
nan 7fffc000000000000000
Signaling NaN
nan 7fa00000
nan 7ff4000000000000
nan 7fffa000000000000000

s bit is 0, so the 7 is correct.  The width of the 
exponet is w = 8, 11, and 15 bits for float, double,
and long double.  The first significant bit, d, is
then 9, 12, and 16.
         s|----w---|d
7fc  --> 0111 1111 1100
7fa  --> 0111 1111 1010
         s|-----w-----| d
7ff8 --> 0111 1111 1111 1000
7ff4 --> 0111 1111 1111 0100
         s|-------w--------| d
7fffc -> 0111 1111 1111 1111 1100 <-- should be 7fff8?
7fffa -> 0111 1111 1111 1111 1010 <-- should be 7fff4?

What does linux/darwin show?

-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[FX]

This is x86_64-linux, with the same source:

$ gcc-10 v.c -fsignaling-nans && ./a.out
Quiet NaN
nan 7fc00000
nan 7ff8000000000000
nan 564e29277fffc000000000000000
Signaling NaN
nan 7fa00000
nan 7ff4000000000000
nan 564e29277fffa000000000000000

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 09:04:05PM +0100, FX wrote:
> This is x86_64-linux, with the same source:
> 
> $ gcc-10 v.c -fsignaling-nans && ./a.out
> Quiet NaN
> nan 7fc00000
> nan 7ff8000000000000
> nan 564e29277fffc000000000000000
> Signaling NaN
> nan 7fa00000
> nan 7ff4000000000000
> nan 564e29277fffa000000000000000
> 

So the 7fffc and 7fffa signatures are equivalent to
what I see on FreeBSD (never seen the 564e2927 string
before).  Maybe an off-by-one bit in issignaling_fallback.h?

-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[FX]

> FAIL: gfortran.dg/ieee/signaling_3.f90   -O0  execution test

For that one, can you confirm it’s a 64-bit run, not -m32?
I’ve fixed that case: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d

FX

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 09:09:15AM +0100, FX wrote:
> > FAIL: gfortran.dg/ieee/signaling_3.f90   -O0  execution test
> 
> For that one, can you confirm it’s a 64-bit run, not -m32?

It looks like a multilib build, but the FreeBSD toolchain
cannot find its ls-elf32.so.1 dynamic loader (or I need
to set appropriate LD_32_* environment during bootstrap).
I'll likely need to engage freebsd-toolchain people to
get multilib working.  I'll disable multilib for now and
do a new bootstrap.

-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 09:09:15AM +0100, FX wrote:
> > FAIL: gfortran.dg/ieee/signaling_3.f90   -O0  execution test
> 
> For that one, can you confirm it’s a 64-bit run, not -m32?
> I’ve fixed that case: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0336ab4e7e2eb58a64d8ee4e5e8083dd53a4d2d
> 

With --disable-multilib, so no -m32 support, I still 
signaling_3.f90 failing.  In

! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
! x87 / x86-32 ABI is unsuitable for signaling NaNs

I have no idea what ilp32 is trying to do, but if the 
second line of the comment means that i387 fpu should be
used, it isn't on freebsd.

-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[FX]

> With --disable-multilib, so no -m32 support, I still 
> signaling_3.f90 failing.  In
> 
> ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> ! x87 / x86-32 ABI is unsuitable for signaling NaNs

This just means the test shouldn’t be run on 32-bit Intel.

Can you run this:

#include <stdint.h>
#include <stdio.h>
#include "issignaling_fallback.h"

int main (void) {
  long double z;
 
  z = __builtin_nansl("");
  printf("%d\n", issignaling(z));

  z = __builtin_nanl("");
  printf("%d\n", issignaling(z));
}

compiled with -fsignaling-nans and the issignaling_fallback.h file from libgfortran?

FX

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 08:52:34PM +0100, FX wrote:
> > With --disable-multilib, so no -m32 support, I still 
> > signaling_3.f90 failing.  In
> > 
> > ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> > ! x87 / x86-32 ABI is unsuitable for signaling NaNs
> 
> This just means the test shouldn’t be run on 32-bit Intel.
> 
> Can you run this:
> 
> #include <stdint.h>
> #include <stdio.h>
> #include "issignaling_fallback.h"
> 
> int main (void) {
>   long double z;
>  
>   z = __builtin_nansl("");
>   printf("%d\n", issignaling(z));
> 
>   z = __builtin_nanl("");
>   printf("%d\n", issignaling(z));
> }
> 
> compiled with -fsignaling-nans and the issignaling_fallback.h file from libgfortran?
> 

% ~/work/x/bin/gcc -o -I. -fsignaling-nans -o z b.c && ./z
0
0

Quickly read issignaling_fallback.h.  It seems you're looking
for bit that distinguishes snan and qnan.  Still need to piece
together exactly what the bit manipulation functions are doing.
-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 08:52:34PM +0100, FX wrote:
> > With --disable-multilib, so no -m32 support, I still 
> > signaling_3.f90 failing.  In
> > 
> > ! { dg-do run { xfail { { i?86-*-* x86_64-*-* } && ilp32 } } }
> > ! x87 / x86-32 ABI is unsuitable for signaling NaNs
> 
> This just means the test shouldn’t be run on 32-bit Intel.
> 
> Can you run this:
> 
> #include <stdint.h>
> #include <stdio.h>
> #include "issignaling_fallback.h"
> 
> int main (void) {
>   long double z;
>  
>   z = __builtin_nansl("");
>   printf("%d\n", issignaling(z));
> 
>   z = __builtin_nanl("");
>   printf("%d\n", issignaling(z));
> }
> 
> compiled with -fsignaling-nans and the issignaling_fallback.h file from libgfortran?
> 

If in issignaling_fallback.h, I change 

#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
   ... 
#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
  ...
#endif

to 

#if 0
   ... 
#else
   ...
#endif

to force little endian, I get

% ~/work/x/bin/gcc -o -I. -fsignaling-nans -o z b.c && ./z
1
0

so need an equivalent of __FLOAT_WORD_ORDER for at least
FreeBSD.  

Found it.  https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Add trailing undersores to __FLOAT_WORD_ORDER and change
__BIG_ENDIAN to __ORDER_BIG_ENDIAN__.  Likewise for LITTLE.

-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[FX]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

> Found it.  https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
> 
> Add trailing undersores to __FLOAT_WORD_ORDER and change
> __BIG_ENDIAN to __ORDER_BIG_ENDIAN__.  Likewise for LITTLE.

Thanks Steve!

What I wonder is: if those conditions failed, then the struct they define should have been empty, and therefore the code shouldn’t compile anyway (that was the intent).

Does the attached patch fix the remaining failures?

FX


[-- Attachment #2: fix.txt --]
[-- Type: text/plain, Size: 1709 bytes --]

commit 03cfe155f46c05e4dda349be2abe467c16789491
Author: Francois-Xavier Coudert <fxcoudert@gmail.com>
Date:   2022-01-25 21:54:03 +0100

    Fortran: fix issignaling() implementation
    
    libgfortran/ChangeLog:
    
            * ieee/issignaling_fallback.h: Fix GCC-specific preprocessor
            macros.

diff --git a/libgfortran/ieee/issignaling_fallback.h b/libgfortran/ieee/issignaling_fallback.h
index 4632bc510f7..fc59481c43b 100644
--- a/libgfortran/ieee/issignaling_fallback.h
+++ b/libgfortran/ieee/issignaling_fallback.h
@@ -103,12 +103,12 @@ typedef union
   long double value;
   struct
   {
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
     int sign_exponent:16;
     unsigned int empty:16;
     uint32_t msw;
     uint32_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
     uint32_t lsw;
     uint32_t msw;
     int sign_exponent:16;
@@ -146,10 +146,10 @@ typedef union
   long double value;
   struct
   {
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
     uint64_t msw;
     uint64_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
     uint64_t lsw;
     uint64_t msw;
 #endif
@@ -191,10 +191,10 @@ typedef union
   __float128 value;
   struct
   {
-#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+#if __FLOAT_WORD_ORDER__ == __ORDER_BIG_ENDIAN__
     uint64_t msw;
     uint64_t lsw;
-#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+#elif __FLOAT_WORD_ORDER__ == __ORDER_LITTLE_ENDIAN__
     uint64_t lsw;
     uint64_t msw;
 #endif

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Tue, Jan 25, 2022 at 09:56:05PM +0100, FX wrote:
> > Found it.  https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
> > 
> > Add trailing undersores to __FLOAT_WORD_ORDER and change
> > __BIG_ENDIAN to __ORDER_BIG_ENDIAN__.  Likewise for LITTLE.
> 
> Thanks Steve!
> 
> What I wonder is: if those conditions failed, then the struct they define should have been empty, and therefore the code shouldn’t compile anyway (that was the intent).
> 
> Does the attached patch fix the remaining failures?
> 

Yes!

% gmake check-fortran RUNTESTFLAGS="ieee.exp=signaling_\*"
...
                === gfortran Summary ===

# of expected passes            24
# of unsupported tests          6


-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[FX]

>> Does the attached patch fix the remaining failures?
> 
> Yes!
> 
> % gmake check-fortran RUNTESTFLAGS="ieee.exp=signaling_\*"
> ...
>                === gfortran Summary ===
> 
> # of expected passes            24
> # of unsupported tests          6

Thanks Steve, pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fa262add75ab6631bf22b7e2884437ba9c62ed2a

FX

Re: New signaling NaN causes 12 testsuite failures

[Tobias Burnus]

On 25.01.22 21:56, FX via Fortran wrote:
> What I wonder is: if those conditions failed, then the struct they define should have been empty, and therefore the code shouldn’t compile anyway (that was the intent).

Wouldn't it make more sense to add '#else' / '#error "...."' in that case?

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: New signaling NaN causes 12 testsuite failures

[Steve Kargl]

On Wed, Jan 26, 2022 at 11:47:27AM +0100, Tobias Burnus wrote:
> On 25.01.22 21:56, FX via Fortran wrote:
> > What I wonder is: if those conditions failed, then the struct they define should have been empty, and therefore the code shouldn’t compile anyway (that was the intent).
> 
> Wouldn't it make more sense to add '#else' / '#error "...."' in that case?
> 

AFAICT, the first condition does not fail due to the missing
trailing underscores.

#if __FLOAT_WORD_ORDER == __BIG_ENDIAN

becomes (I believe)

#if 0 == 0

so FreeBSD was using big endian in FX's issignaling_fallback
when it needed little endian.

PS: Thanks FX for your patch!


-- 
Steve

Re: New signaling NaN causes 12 testsuite failures

[FX]

> AFAICT, the first condition does not fail due to the missing
> trailing underscores.
> 
> #if __FLOAT_WORD_ORDER == __BIG_ENDIAN
> 
> becomes (I believe)
> 
> #if 0 == 0
> 
> so FreeBSD was using big endian in FX's issignaling_fallback
> when it needed little endian.

Yeah that makes total sense.

FX