From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout2.netcologne.de (cc-smtpout2.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:2]) by sourceware.org (Postfix) with ESMTPS id EFD423858430 for ; Tue, 16 Nov 2021 07:51:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EFD423858430 Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id BBFF612721; Tue, 16 Nov 2021 08:51:17 +0100 (CET) Received: from [IPv6:2001:4dd7:10ca:0:7285:c2ff:fe6c:992d] (2001-4dd7-10ca-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:10ca: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 (2048 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA id 7137011DCD; Tue, 16 Nov 2021 08:51:08 +0100 (CET) Subject: Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes To: Michael Meissner , Bill Schmidt , "fortran@gcc.gnu.org" , Jakub Jelinek , Segher Boessenkool , Peter Bergner , David Edelsohn References: <63b5434e-f8fa-97b3-d357-e25094579b16@netcologne.de> <628c8da1-9661-16ca-a5e2-45d27498b9fc@netcologne.de> From: Thomas Koenig Message-ID: <662a32fd-0daf-cb92-8e7d-e6858ec89994@netcologne.de> Date: Tue, 16 Nov 2021 08:51:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: 7137011DCD X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 07:51:22 -0000 On 16.11.21 00:42, Michael Meissner wrote: > On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote: >> Hi, >> >> is there an update on this? I am still waiting on a response for >> the account on the development machine. >> >> I assume we would to the development on a branch. My git fu >> is extremely weak, so I would appreciate if somebody did that >> for me. > > Sure, we can create an IBM vendor branch. > >> Is it actually possible to implement what I wrote in the draft >> documentation patch, or is there some problem (like gmp >> or mpfr depending on one of the types at compile-time)? >> >> If so, I think we should go for it; if not, then we have to make >> another decision. > > Well there are a couple of things that need to be done. A lot are fortran > specific type things, so while I can attempt to do these things, I don't know > the structure of the front end or library. > >>From my previous test patches, I think it is a disaster if KIND=16 is not the > same as C/C++ long double by default. It opens up all sorts of problems. But > then it may be the Fortran users would like that flexibility. That is your > call. > > I think the most important thing is defining the library interface and naming > scheme. So we need to switch calls to one name or another based on the default > long double format. I don't know what naming scheme you use, but it should be > fairly simple. > > For the C/C++/math built-ins, we use the traditional name with an 'l' suffix if > long double is IBM double-double, and a 'f128' suffix if long double is IEEE > 128-bit. The PowerPC backend will automatically switch names for built-ins it > knows about. That is where I come in, I think. > However, my tests showed there are a bunch of functions that are in the math > library that are not built-ins. For C/C++, this is not an issue, because > math.h will do this switching. We would need some way for Fortran to do it for > the other functions. OK. Looking at a random sample, libgfortran/generated/maxloc0_4_r4.c , has #if defined (HAVE_GFC_REAL_4) && defined (HAVE_GFC_INTEGER_4) extern void maxloc0_4_r4 (gfc_array_i4 * const restrict retarray, gfc_array_r4 * const restrict array, GFC_LOGICAL_4); which is expanded by m4 from maxloc0.m4, which in turn includes iforeach.m4, which has name`'rtype_qual`_'atype_code (rtype * const restrict retarray, atype * const restrict array, GFC_LOGICAL_4 back) where the parameters are determined from the file name. So we can put in a file maxloc0_4_r17 into the normal build process, which will give us #if defined (HAVE_GFC_REAL_17) && defined (HAVE_GFC_INTEGER_4) Next thing to do would be to put the file into libgfortran/Makefile.am, making sure that it is compiled with the right options. There will have to be some condition on the compilation that we do not compile the files on non-POWER-systems. Next, we need to define GFC_REAL_17 as IEEE QP on POWER (only there of course), probably in libgfortran/kinds-override.h. For compiling, there has to be a flag in the compiler to let us know what we are compiling for, so we can call the different functions depending on the flag. > Once we have the naming scheme, then we need to modify the library build, so > that it will build both types of modules with the appropriate flags. Yep. > Once the library is set up to have both names, then we can start to think about > the user overriding the defaults. This is probably a thing that needs the > Fortran folk to do, since there may be various rules of what can be done. But > for the initial work, I think the most important thing is getting the library > so it has both names in it, so a user/distro could start to move the default > floating point type. I can start working on that, once the following are in (or documented): - A global configure script that determines if there is a target which supports both IEEE QP and double double. - A conditional suitable for Makefile.am on libgfortran to check for that condition - A preprocessor directive in the compiler to check if IEEE and QP are supported with the right flag - A compiler flag to select either IEEE QP or double double as default - A global flag to check if IEEE or double double is enabled >> Due to my day job, my time for working on this project is rather >> limited, and in my experience it is easier to finish something if >> it is actually started :-) >> >> So, who does what? I work on the gfortran internals (library interface) >> and the library itself, but I would need some prior work to set up the >> compiler so things work up to that particular point. >> >> Or have we missed the window due to gcc being in stage 3 now? > > This may be an issue for the release and Fortran maintainers. Even if we can't > put it in right now, I think it is important to start work so it can be put in > at a later date. I'd say we would need a global reviewer's OK for that, plus of course from a POWER maintainer, but that should not be a problem :-) > In terms of my schedule, I will be available for doing whatever is needed until > December 20th. I have a hard stop then as I will be doing a family trip for > Christmas and I will not be available after that. I won't be back until the > new year. I believe Bill and Peter feel this is one of the most important uses > of my time in the next month or so. But bear in mind, I don't know much about > the Fortran front end, nothing about the library, or knowing Fortran at all. If you could start working on the points above, that would be great. Best regards Thomas