From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id B05463857C70 for ; Tue, 25 Jan 2022 17:42:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B05463857C70 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 20PHg4KC055647 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 25 Jan 2022 09:42:04 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 20PHg4Br055646; Tue, 25 Jan 2022 09:42:04 -0800 (PST) (envelope-from sgk) Date: Tue, 25 Jan 2022 09:42:04 -0800 From: Steve Kargl To: FX Cc: fortran@gcc.gnu.org Subject: Re: New signaling NaN causes 12 testsuite failures Message-ID: <20220125174204.GA74530@troutmask.apl.washington.edu> References: <20220125004453.GA16729@troutmask.apl.washington.edu> <20220125024811.GA19308@troutmask.apl.washington.edu> <93B4F458-9AD2-44DA-9F21-37B16C4A0CE8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93B4F458-9AD2-44DA-9F21-37B16C4A0CE8@gmail.com> X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 17:42:07 -0000 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 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