* New signaling NaN causes 12 testsuite failures @ 2022-01-25 0:44 Steve Kargl 2022-01-25 2:48 ` Steve Kargl 2022-01-25 8:09 ` FX 0 siblings, 2 replies; 19+ messages in thread From: Steve Kargl @ 2022-01-25 0:44 UTC (permalink / raw) To: fortran, fxcoudert % 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 0:44 New signaling NaN causes 12 testsuite failures Steve Kargl @ 2022-01-25 2:48 ` Steve Kargl 2022-01-25 8:05 ` FX 2022-01-25 8:09 ` FX 1 sibling, 1 reply; 19+ messages in thread From: Steve Kargl @ 2022-01-25 2:48 UTC (permalink / raw) To: fortran, fxcoudert 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 2:48 ` Steve Kargl @ 2022-01-25 8:05 ` FX 2022-01-25 17:42 ` Steve Kargl 2022-01-25 19:59 ` Steve Kargl 0 siblings, 2 replies; 19+ messages in thread From: FX @ 2022-01-25 8:05 UTC (permalink / raw) To: Steve Kargl; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 8:05 ` FX @ 2022-01-25 17:42 ` Steve Kargl 2022-01-25 19:59 ` Steve Kargl 1 sibling, 0 replies; 19+ messages in thread From: Steve Kargl @ 2022-01-25 17:42 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 8:05 ` FX 2022-01-25 17:42 ` Steve Kargl @ 2022-01-25 19:59 ` Steve Kargl 2022-01-25 20:04 ` FX 1 sibling, 1 reply; 19+ messages in thread From: Steve Kargl @ 2022-01-25 19:59 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 19:59 ` Steve Kargl @ 2022-01-25 20:04 ` FX 2022-01-25 20:20 ` Steve Kargl 0 siblings, 1 reply; 19+ messages in thread From: FX @ 2022-01-25 20:04 UTC (permalink / raw) To: Steve Kargl; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 20:04 ` FX @ 2022-01-25 20:20 ` Steve Kargl 0 siblings, 0 replies; 19+ messages in thread From: Steve Kargl @ 2022-01-25 20:20 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 0:44 New signaling NaN causes 12 testsuite failures Steve Kargl 2022-01-25 2:48 ` Steve Kargl @ 2022-01-25 8:09 ` FX 2022-01-25 16:52 ` Steve Kargl 2022-01-25 19:35 ` Steve Kargl 1 sibling, 2 replies; 19+ messages in thread From: FX @ 2022-01-25 8:09 UTC (permalink / raw) To: Steve Kargl; +Cc: fortran > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 8:09 ` FX @ 2022-01-25 16:52 ` Steve Kargl 2022-01-25 19:35 ` Steve Kargl 1 sibling, 0 replies; 19+ messages in thread From: Steve Kargl @ 2022-01-25 16:52 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 8:09 ` FX 2022-01-25 16:52 ` Steve Kargl @ 2022-01-25 19:35 ` Steve Kargl 2022-01-25 19:52 ` FX 1 sibling, 1 reply; 19+ messages in thread From: Steve Kargl @ 2022-01-25 19:35 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 19:35 ` Steve Kargl @ 2022-01-25 19:52 ` FX 2022-01-25 20:12 ` Steve Kargl 2022-01-25 20:45 ` Steve Kargl 0 siblings, 2 replies; 19+ messages in thread From: FX @ 2022-01-25 19:52 UTC (permalink / raw) To: Steve Kargl; +Cc: fortran > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 19:52 ` FX @ 2022-01-25 20:12 ` Steve Kargl 2022-01-25 20:45 ` Steve Kargl 1 sibling, 0 replies; 19+ messages in thread From: Steve Kargl @ 2022-01-25 20:12 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 19:52 ` FX 2022-01-25 20:12 ` Steve Kargl @ 2022-01-25 20:45 ` Steve Kargl 2022-01-25 20:56 ` FX 1 sibling, 1 reply; 19+ messages in thread From: Steve Kargl @ 2022-01-25 20:45 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 20:45 ` Steve Kargl @ 2022-01-25 20:56 ` FX 2022-01-25 21:05 ` Steve Kargl 2022-01-26 10:47 ` Tobias Burnus 0 siblings, 2 replies; 19+ messages in thread From: FX @ 2022-01-25 20:56 UTC (permalink / raw) To: Steve Kargl; +Cc: fortran [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 20:56 ` FX @ 2022-01-25 21:05 ` Steve Kargl 2022-01-25 23:11 ` FX 2022-01-26 10:47 ` Tobias Burnus 1 sibling, 1 reply; 19+ messages in thread From: Steve Kargl @ 2022-01-25 21:05 UTC (permalink / raw) To: FX; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 21:05 ` Steve Kargl @ 2022-01-25 23:11 ` FX 0 siblings, 0 replies; 19+ messages in thread From: FX @ 2022-01-25 23:11 UTC (permalink / raw) To: Steve Kargl; +Cc: fortran >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-25 20:56 ` FX 2022-01-25 21:05 ` Steve Kargl @ 2022-01-26 10:47 ` Tobias Burnus 2022-01-26 16:02 ` Steve Kargl 1 sibling, 1 reply; 19+ messages in thread From: Tobias Burnus @ 2022-01-26 10:47 UTC (permalink / raw) To: FX, Steve Kargl; +Cc: fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-26 10:47 ` Tobias Burnus @ 2022-01-26 16:02 ` Steve Kargl 2022-01-26 16:19 ` FX 0 siblings, 1 reply; 19+ messages in thread From: Steve Kargl @ 2022-01-26 16:02 UTC (permalink / raw) To: Tobias Burnus; +Cc: FX, fortran 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: New signaling NaN causes 12 testsuite failures 2022-01-26 16:02 ` Steve Kargl @ 2022-01-26 16:19 ` FX 0 siblings, 0 replies; 19+ messages in thread From: FX @ 2022-01-26 16:19 UTC (permalink / raw) To: Steve Kargl; +Cc: Tobias Burnus, fortran > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-01-26 16:19 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-25 0:44 New signaling NaN causes 12 testsuite failures Steve Kargl 2022-01-25 2:48 ` Steve Kargl 2022-01-25 8:05 ` FX 2022-01-25 17:42 ` Steve Kargl 2022-01-25 19:59 ` Steve Kargl 2022-01-25 20:04 ` FX 2022-01-25 20:20 ` Steve Kargl 2022-01-25 8:09 ` FX 2022-01-25 16:52 ` Steve Kargl 2022-01-25 19:35 ` Steve Kargl 2022-01-25 19:52 ` FX 2022-01-25 20:12 ` Steve Kargl 2022-01-25 20:45 ` Steve Kargl 2022-01-25 20:56 ` FX 2022-01-25 21:05 ` Steve Kargl 2022-01-25 23:11 ` FX 2022-01-26 10:47 ` Tobias Burnus 2022-01-26 16:02 ` Steve Kargl 2022-01-26 16:19 ` FX
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).