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 F30623858C20; Thu, 8 Jun 2023 16:31:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F30623858C20 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 358GVnGm031725 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 8 Jun 2023 09:31:49 -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 358GVmQM031724; Thu, 8 Jun 2023 09:31:48 -0700 (PDT) (envelope-from sgk) Date: Thu, 8 Jun 2023 09:31:48 -0700 From: Steve Kargl To: Thomas Koenig Cc: Harald Anlauf via Fortran , FX Coudert , gcc-patches@gcc.gnu.org, Michael Meissner Subject: Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <34D02A51-4240-4816-B874-54D7CFFE9FC6@gmail.com> <2d99383a-b114-db00-8083-33894492252f@gmx.de> 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 Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote: > Hi together, > > > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote: > > > > Hi, > > > > > > > > > I cannot see if there is proper support for kind=17 in your patch; > > > > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not > > > > > seem to have any related code. > > > > > > > > Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong happened, because the IEEE modules have no kind=17 mention in them anywhere. > > > > > > > > Actually, where is the kind=17 documented? > > > > > > > > FX > > > > > > I was hoping for Thomas to come forward with some comment, as > > > he was quite involved in related work. > > > > > > There are several threads on IEEE128 for Power on the fortran ML > > > e.g. around November/December 2021, January 2022. > > > > > > I wasn't meaning to block your work, just wondering if the Power > > > platform needs more attention here. > > > > > > > % cd gcc/gccx/libgfortran > > % grep HAVE_GFC_REAL_17 ieee/* > > % troutmask:sgk[219] ls ieee > > % ieee_arithmetic.F90 ieee_features.F90 > > % ieee_exceptions.F90 ieee_helper.c > > > > There are zero hits for REAL(17) in the IEEE code. If REAL(17) > > is intended to be an IEEE-754 type, then it seems gfortran's > > support was never added for it. If anyone has access to a > > power system, it's easy to test > > > > program foo > > use ieee_arithmetic > > print *, ieee_support_datatype(1.e_17) > > end program foo > > The KIND=17 is a bit of a kludge. It is not visible for > user programs, they use KIND=16, but this is then translated > to library calls as if it was KIND=17 if the IEEE 128-bit floats > are selected: > > $ cat ml.f90 > subroutine mm(a) > real(kind=16), dimension(:,:) :: a > print *,maxloc(a) > end subroutine mm > $ gfortran -S -mabi=ieeelongdouble ml.f90 && grep maxloc ml.s > bl _gfortran_maxloc0_4_r17 > $ gfortran -S ml.f90 && grep maxloc ml.s > bl _gfortran_maxloc0_4_r16 > > On POWER, if IBM long double exists, it is GFC_REAL_16, with GFC_REAL_17 > being IEEE long double. Everywhere else, GFC_REAL_16 is IEEE long > double. > > If POWER gets the flag -mabi=ieeelongdouble, it uses IEEE long doubles. > > If it gets the additionalflag -mcpu=power9 or -mcpu=power10, it uses > the hardware instructions for the arithmetic instead of library calls. > (trimming for length) Thanks for the explanation. As I likely will not use a POWER-based system, I only loosely followed the discussion. I don't remember if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is REAL(16), then everything should (I believe) be okay. > There is a virutal POWER machine at OSUL dedicated to the IEEE QP > gfortran effort. It hasn't been used for some time, but it's still > active. I just bootstrapped trunk there and ran all the IEEE from the > testsuite manually, with > > $ for a in *.f90; do echo "Testing $a"; gfortran -o $a.exe -fno-range-check > -mcpu=power9 -mabi=ieeelongdouble -static-libgfortran $a signaling_1_c.c > signaling_2_c.c ; ./$a.exe ; done 2>&1 | grep -v command-line > Testing fma_1.f90 These could be misleading. gfortran has pre-processor tokens for REAL(10) and REAL(16). If __GFC_REAL_16__ isn't defined the ieee testing is skipped. % cd gcc/gccx/gcc/fortran/ % grep __GFC_REAL_ * cpp.cc: cpp_define (cpp_in, "__GFC_REAL_10__=1"); cpp.cc: cpp_define (cpp_in, "__GFC_REAL_16__=1"); invoke.texi:@code{__GFC_REAL_10__}, and @code{__GFC_REAL_16__}. % more cpp.cc ... /* Pre-defined macros for non-required REAL kind types. */ for (gfc_real_info *rtype = gfc_real_kinds; rtype->kind != 0; rtype++) { if (rtype->kind == 10) cpp_define (cpp_in, "__GFC_REAL_10__=1"); if (rtype->kind == 16) cpp_define (cpp_in, "__GFC_REAL_16__=1"); } ... Should we have a __GFC_REAL_17__? % cd ../testsuite/gfortran.dg/ % grep __GFC_REAL ieee/* ieee/dec_math_1.f90: ! Note however that if both __GFC_REAL_10__ and __GFC_REAL_16__ are defined, ieee/dec_math_1.f90:#if defined(__GFC_REAL_10__) ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__) ieee/dec_math_1.f90:#ifdef __GFC_REAL_10__ ieee/dec_math_1.f90:#elif defined(__GFC_REAL_16__) ieee/dec_math_1.f90:#ifdef __GFC_REAL_16__ ieee/dec_math_1.f90:#elif defined(__GFC_REAL_10__) ieee/ieee_11.F90:#ifdef __GFC_REAL_10__ ieee/ieee_11.F90:#ifdef __GFC_REAL_16__ -- Steve