From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117219 invoked by alias); 21 Dec 2018 18:59:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 117183 invoked by uid 89); 21 Dec 2018 18:59:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=xn, MAX_EXPR, 08AM, max_expr X-HELO: mail-yb1-f196.google.com Received: from mail-yb1-f196.google.com (HELO mail-yb1-f196.google.com) (209.85.219.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Dec 2018 18:59:19 +0000 Received: by mail-yb1-f196.google.com with SMTP id q145so934564ybq.9; Fri, 21 Dec 2018 10:59:19 -0800 (PST) MIME-Version: 1.0 References: <20181220214739.GA86993@troutmask.apl.washington.edu> <20181221062240.GA99794@troutmask.apl.washington.edu> <20181221175953.GA3659@troutmask.apl.washington.edu> In-Reply-To: <20181221175953.GA3659@troutmask.apl.washington.edu> From: Janne Blomqvist Date: Fri, 21 Dec 2018 19:11:00 -0000 Message-ID: Subject: Re: [PATCH] fortran/69121 -- Make IEEE_SCALB generic To: Steve Kargl Cc: Fortran List , GCC Patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-12/txt/msg01598.txt.bz2 On Fri, Dec 21, 2018 at 7:59 PM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Fri, Dec 21, 2018 at 11:07:08AM +0200, Janne Blomqvist wrote: > > On Fri, Dec 21, 2018 at 8:22 AM Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > On Thu, Dec 20, 2018 at 01:47:39PM -0800, Steve Kargl wrote: > > > > The attached patch has been tested on x86_64-*-freebsd. > > > > > > > > OK to commit? > > > > > > > > 2018-12-20 Steven G. Kargl > > > > > > > > PR fortran/69121 > > > > * libgfortran/ieee/ieee_arithmetic.F90: Provide missing > functions > > > > in interface for IEEE_SCALB. > > > > > > > > 2018-12-20 Steven G. Kargl > > > > > > > > PR fortran/69121 > > > > * gfortran.dg/ieee/ieee_9.f90: New test. > > > > > > Now, tested on i586-*-freebsd. > > > > > > > Hi, looks ok for trunk. > > > > A few questions popped into my mind while looking into this: > > > > 1) Why are none of the _gfortran_ieee_scalb_X_Y functions mentioned in > > gfortran.map? I guess they should all be there? > > > > 2) Currently all the intrinsics map to the scalbn{,f,l} builtins. > However, > > when the integer argument is of kind int64 or int128 we should instead > use > > scalbln{,f,l}. This also applies to other intrinsics that use scalbn > under > > the hood. > > > > To clarify, fixing these is not a prerequisite for accepting the patch (I > > already accepted it), but more like topics for further work. > > > > I forgot to address your had a 2) item above. ieee_scalb appears > to do the right thing. FX addressed that with his implementation. > The 2nd argument is always cast to integer after reducing the range > to that of integer(4). > > The binary floating point representation for a REAL(16) finite number > is x=f*2**e with f in [0.5,1) and e in [-16059,16384]. scalb(x,n) is > x*2**n, which becomes f*2**e*2**n = f*2**(e+n). If x is the smallest > positive subnormal number, then n can be at most 32443 to still return > a finite REAL(16) number. Any larger value overflows to infinity. > If x is the largest positive finite number, then n can be -32443 to > return the small positive subnormal number. Any more negative value > of n underflows to zero. (Note, I could be off-by-one, but that is > just a detail.) > > Consider > > function foo(x,i) > use ieee_arithmetic > real(16) foo, c > integer(8) i > print *, ieee_scalb(c, i) > end function foo > > -fdump-tree-original gives > > D.3853 = *i; > __result_foo = scalbnq (c, > (integer(kind=4)) MAX_EXPR , > -2147483647>); > > The range [-32443,32443] is a subset of [-huge(),huge(0)]. > True. I guess the advantage of scalbln* would be to avoid the MAX/MIN_EXPR and casting for kind int64. -- Janne Blomqvist