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 C46FD3858C78; Fri, 14 Apr 2023 21:19:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C46FD3858C78 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 33ELJd1j048133 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Apr 2023 14:19:39 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 33ELJcH3048132; Fri, 14 Apr 2023 14:19:38 -0700 (PDT) (envelope-from sgk) Date: Fri, 14 Apr 2023 14:19:38 -0700 From: Steve Kargl To: Harald Anlauf Cc: Harald Anlauf via Fortran , gcc-patches Subject: Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511] Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Apr 14, 2023 at 09:49:22PM +0200, Harald Anlauf wrote: > > On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote: > > I was wondering about the difference between set_exponent() > > and scale(), and found that set_exponent() talks about IEEE > > values while scale() doesn't. I'm wondering if we should > > add the IEEE special cases to the testsuite. Of particular > > note, I doubt that this is true: > > > > If X is an IEEE NaN, the result is the same NaN. > > > > program foo > > real x, y > > x = 1 > > y = x - x > > x = (x - x) / y > > print '(F4.0,1X,Z8.8)', x, x > > y = set_exponent(x,1) > > print '(F4.0,1X,Z8.8)', y, y > > end program foo > > > > gfcx -o z a.f90 && ./z > > NaN FFC00000 > > NaN 7FC00000 > > > > Those are not the same NaN. The second is a qNaN. > > The first looks like a qNaN with the sign bit set. > > Until now there was no testing at all of SET_EXPONENT in the testsuite. > It would be really good to have better coverage of compile-time and > runtime behavior of the intrinsics and checking consistency ... ;-) > > I think you have much more experience in that area. (Hint!) > I might have some experience. :-) Unfortunately, I have no time (for at least 4-5 years) to jump down that rabbit hole (as I would try to fix things ;-). However, writing testcases to exercise the intrinsic subprograms is something that the LURKERS here in the mailing list might comtemplate. Any takers? Note returning the 'same Nan" is not special to set_exponent(). At least, fraction() and rrspacing() have "If X is an IEEE NaN, the result is that NaN." Oh, and thanks for your relentless assault on bugs. -- Steve