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 D054C3858C54; Wed, 7 Jun 2023 18:50:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D054C3858C54 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 357Io9Kl024785 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Jun 2023 11:50:09 -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 357Io9mr024784; Wed, 7 Jun 2023 11:50:09 -0700 (PDT) (envelope-from sgk) Date: Wed, 7 Jun 2023 11:50:09 -0700 From: Steve Kargl To: Harald Anlauf via Fortran Cc: FX Coudert , gcc-patches@gcc.gnu.org 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 Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote: > Hi FX, > > 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 -- Steve