From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 1B63C385841F for ; Mon, 15 Nov 2021 23:42:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B63C385841F Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1AFMHsns021613; Mon, 15 Nov 2021 23:42:23 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3cc07k98vm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Nov 2021 23:42:23 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1AFNfsOY029651; Mon, 15 Nov 2021 23:42:22 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 3cc07k98vc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Nov 2021 23:42:22 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1AFNchMW020687; Mon, 15 Nov 2021 23:42:21 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma02dal.us.ibm.com with ESMTP id 3ca50bad6q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Nov 2021 23:42:21 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1AFNgKnY66322924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Nov 2021 23:42:20 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 96F572805E; Mon, 15 Nov 2021 23:42:20 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4CE4F28060; Mon, 15 Nov 2021 23:42:20 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.237.52]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTPS; Mon, 15 Nov 2021 23:42:20 +0000 (GMT) Date: Mon, 15 Nov 2021 18:42:18 -0500 From: Michael Meissner To: Thomas Koenig Cc: Michael Meissner , Bill Schmidt , "fortran@gcc.gnu.org" , Jakub Jelinek , Segher Boessenkool , Peter Bergner , David Edelsohn Subject: Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes Message-ID: Mail-Followup-To: Michael Meissner , Thomas Koenig , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <628c8da1-9661-16ca-a5e2-45d27498b9fc@netcologne.de> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 7Nu9dQGm-vYojhti6l5ZNNfLKaD-8J_q X-Proofpoint-GUID: lPPoociwOsyuH4UlcivkbQy4uCx4ujFf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-15_16,2021-11-15_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 phishscore=0 malwarescore=0 mlxscore=0 clxscore=1015 impostorscore=0 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111150119 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Mon, 15 Nov 2021 23:42:28 -0000 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. 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. 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. 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. > 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. 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. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com