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 96D593858C33; Sun, 11 Jun 2023 09:50:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 96D593858C33 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-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id EC4D01268F; Sun, 11 Jun 2023 11:50:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1686477052; bh=la+t4J7kzIb48U8cZO+Vjr6cMuprCaB1TrHFEtfBfUM=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BUZQiyg+/HXwppQjhtyfrZrYUybcGDAyKQNe8bGwFzR9/NcgA2GJ4A0YrlVl5Biey AW4YTBJt9UjZEV1Q6klVnYhmTpUOkzEU1MVZo5kyldcH6zAbYDfrTvFDVcXzVGTROC zeimny01wB91jBAvu/BWAvIvOo38cw89I7U4MGTSVNoHBbKQ6YlQwFfjpzpS/uc+Tr JWphtnVt6ZfPCNJe5/ixWU5V3EzFhM/FMuyGzvtoFPHU56D0OnRMY0DwzhDk98r+nI aNiHOnI4PozJhYcG02jjuzuvRnFK2yJKlM7vh7t+PnfCTMcdCCT8OR8WQFoN5PeZCp s2mz+gV17mxnQ== 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-smtpin1.netcologne.de (Postfix) with ESMTPSA id EBE2311D91; Sun, 11 Jun 2023 11:50:46 +0200 (CEST) Message-ID: Date: Sun, 11 Jun 2023 11:50:46 +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: FX Coudert Cc: sgk@troutmask.apl.washington.edu, Harald Anlauf via Fortran , gcc-patches@gcc.gnu.org, Michael Meissner References: <34D02A51-4240-4816-B874-54D7CFFE9FC6@gmail.com> <2d99383a-b114-db00-8083-33894492252f@gmx.de> <38FC9C0B-84A0-43F9-A2B9-4F404A14E083@gmail.com> From: Thomas Koenig In-Reply-To: <38FC9C0B-84A0-43F9-A2B9-4F404A14E083@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NetCologne-Spam: L X-Rspamd-Action: no action X-Rspamd-Queue-Id: EBE2311D91 X-Spamd-Bar: ---- X-Spam-Status: No, score=-3.7 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 FX, >> 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 > > Can you check what the IEEE test results are when -mabi=ieeelongdouble is enabled? Running nohup make -j7 check-fortran RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"& from the gcc subdirectory yielded only a single failure: grep ^FAIL nohup.out FAIL: gfortran.dg/gomp/target-update-1.f90 -O scan-tree-dump gimple "#pragma omp target update to\\(c \\[len: [0-9]+\\]\\) to\\(present:a \\[len: [0-9]+\\]\\) to\\(e \\[len: [0-9]+\\]\\) from\\(present:b \\[len: [0-9]+\\]\\) from\\(d \\[len: [0-9]+\\]\\) and also ran the correct tests, as seen from gfortran.log; for example: Executing on host: gfortran /home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 -mabi=ieeelongdouble -mcpu=power9 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -pedantic-errors -fintrinsic-modules-path /home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans -lm -o ./large_2.exe (timeout = 300) spawn -ignore SIGHUP gfortran /home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 -mabi=ieeelongdouble -mcpu=power9 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -pedantic-errors -fintrinsic-modules-path /home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans -lm -o ./large_2.exe^M PASS: gfortran.dg/ieee/large_2.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/tkoenig/lib/../lib64:.:/home/tkoenig/lib/../lib64 Execution timeout is: 300 spawn [open ...]^M PASS: gfortran.dg/ieee/large_2.f90 -O0 execution test This is a test that fails on POWER with the IBM long double format, so things look ok. It also works when compiled individually. So, this is looking good. By the way, if you or any other gfortran maintainer would like an account on the POWER virtual machine in question, that would be no problem. I would ask the cluster administrators for permission and then create the account (I have admin privileges on that virtual machine). > It’s not even clear to me what the IEEE kinds selected should be, in this case, depending on -mabi=ieeelongdouble The "KIND=17" stuff should only be visible inside the library. > >> 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. > > Actually, it sounds like the situation is: the same target can > have two ABIs based on a compile-time flag. That sounds like a job > for multilib, i.e., we should compile libgfortran twice, one for > each ABI. I am sure> this was considered and rejected, do you > remember what was the rationale? I don't remember discussing multilib in this context, sorry. Best regards Thomas