From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 2C2583857022 for ; Fri, 14 Apr 2023 19:49:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C2583857022 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pnPQG-0009WH-T9 for gcc-patches@gcc.gnu.org; Fri, 14 Apr 2023 21:49:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT [PR109511] Date: Fri, 14 Apr 2023 21:49:22 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20230414194922.b4DyOUfn-bTWCc7ZXNMrVv0y5yNIJYt_LfDdVZSp8HU@z> Hi Steve, On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote: > On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote: >> >> the compile-time simplification of intrinsic SET_EXPONENT was >> broken since the early days of gfortran for argument X < 1 >> (including negative X) and for I < 0. I identified and fixed >> several issues in the implementation. The testcase explores >> argument space comparing compile-time and runtime results and >> is checked against Intel. >> >> Regtested on x86_64-pc-linux-gnu. OK for mainline? >> > > Yes, it is certainly better than the current situation. > >> This is not a regression, but can lead to wrong code. >> Would it be OK to backport to open branches? > > Sure. Looks simply and fairly specific. OK, thanks, will proceed. > 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!) Cheers, Harald