From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [89.1.8.211]) by sourceware.org (Postfix) with ESMTPS id DC6483858C62; Thu, 8 Jun 2023 10:17:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC6483858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=netcologne.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=netcologne.de Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 1967112740; Thu, 8 Jun 2023 12:17:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1686219428; bh=16uKTVqZZph7Nl53SrMfDcm368WCAuyMRheHTMz7yns=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fc/9ZVBLjwGJf0Xb3PhH20XhO8Oso0Bn4jtpVUQPHZGlpMhZNRkuDRiYcBZNoXAjw B3C5YAZMOcxNd8jasVkpDeoFLSqgV6f/go8T2cd+vMwtPk4QtjXRbSaTrs3yEiWLP0 vrGQPMUObbhDBgNmD5WLL0YO5nxiNQJ/UonP6fojhucJS6odjm5R9HC/ItYg0cJkB+ +I7i8bT7ksfTWbi4X/N8sOp9QpCpCGMucoBQti9bqN7Zkko3E/05EDHrgOuiE3wIkD Pigv4Jihk9nK8RXUB4dETKbTfEehWH2/0+pIbmF1Lr8nTUTh4CbXU3wjBd+2kxZX8B LrdwdJaFFfNfA== Received: from [IPV6:2001:4dd7:2d6e:0:7285:c2ff:fe6c:992d] (2001-4dd7-2d6e-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:2d6e:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id 8F71C120D0; Thu, 8 Jun 2023 12:17:03 +0200 (CEST) Message-ID: Date: Thu, 8 Jun 2023 12:17:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions Content-Language: en-US To: sgk@troutmask.apl.washington.edu, Harald Anlauf via Fortran Cc: FX Coudert , gcc-patches@gcc.gnu.org, Michael Meissner References: <34D02A51-4240-4816-B874-54D7CFFE9FC6@gmail.com> <2d99383a-b114-db00-8083-33894492252f@gmx.de> From: Thomas Koenig In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Rspamd-Action: no action X-Rspamd-Queue-Id: 8F71C120D0 X-Spamd-Bar: ---- X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: 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. Having a POWER system isn't enough, it also needs the IBM "advance toolchain", and (at least with current distros, which default to ibm long double), you need to dance counterclockwise three times... I mean you need to invoke configure with some special magic like configure \ --prefix=$HOME \ --enable-languages=c,c++,fortran \ --disable-plugin \ --enable-checking \ --enable-stage1-checking \ --enable-gnu-indirect-function \ --disable-maintainer-mode \ --disable-libgomp \ --enable-decimal-float \ --enable-secureplt \ --enable-threads=posix \ --enable-__cxa_atexit \ --with-cpu=power9 \ --with-long-double-128 \ --with-as=/opt/at15.0/bin/as \ --with-ld=/opt/at15.0/bin/ld \ --with-gnu-as=/opt/at15.0/bin/as \ --with-gnu-ld=/opt/at15.0/bin/ld \ --with-advance-toolchain=at15.0 \ --with-native-system-header-dir=/opt/at15.0/include \ --without-ppl \ --without-cloog \ --without-isl which Michael Meissner helped me with, I would never have figured it out on my own. 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 2.00000000 1.50000000 2.0000000000000000 1.5000000000000000 2.00000000000000000000000000000000000 1.50000000000000000000000000000000000 2.0000000000000000 1.5000000000000000 Testing ieee_10.f90 Testing ieee_12.f90 Testing ieee_2.f90 Testing ieee_3.f90 Testing ieee_4.f90 Testing ieee_5.f90 Testing ieee_6.f90 Testing ieee_7.f90 Testing ieee_8.f90 Testing ieee_9.f90 Testing intrinsics_1.f90 Testing large_1.f90 Testing large_2.f90 Testing large_4.f90 Testing modes_1.f90 Testing pr77372.f90 Testing pr77507.f90 -Infinity F Testing rounding_1.f90 Testing rounding_2.f90 Testing rounding_3.f90 Testing signaling_1.f90 Testing signaling_2.f90 Testing signaling_3.f90 Testing signbit_1.f90 Testing underflow_1.f90 so that seems to be OK. However, the fact that there is no mention of GFC_REAL_17 in there makes me a bit suspicious, Michael, maybe you can comment if all is indeed well there, and if the right things are being tested? Regarding FX's patch: I am not quite sure that I am actually testing the right thing if running the testsuite there, so POWER should not hold up this patch. If it turns out that POWER needs additonal work on IEEE, we can always add that later. Best regards Thomas