From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id B282F3858001 for ; Mon, 1 Nov 2021 18:46:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B282F3858001 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1A1IceX6024656; Mon, 1 Nov 2021 18:46:49 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3c2kjntufk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Nov 2021 18:46:49 +0000 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1A1IdC7h026564; Mon, 1 Nov 2021 18:46:48 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 3c2kjntuf1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Nov 2021 18:46:48 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1A1IblVj015597; Mon, 1 Nov 2021 18:46:47 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma01dal.us.ibm.com with ESMTP id 3c0wpbbbqp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Nov 2021 18:46:47 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1A1Ikktx11665986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 1 Nov 2021 18:46:46 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6F5E5124055; Mon, 1 Nov 2021 18:46:46 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 18D05124052; Mon, 1 Nov 2021 18:46:46 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.31.33]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTPS; Mon, 1 Nov 2021 18:46:46 +0000 (GMT) Date: Mon, 1 Nov 2021 14:46:44 -0400 From: Michael Meissner To: Bill Schmidt Cc: Thomas Koenig , "fortran@gcc.gnu.org" , Jakub Jelinek , Segher Boessenkool , Peter Bergner , David Edelsohn , Michael Meissner Subject: Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes Message-ID: Mail-Followup-To: Michael Meissner , Bill Schmidt , Thomas Koenig , "fortran@gcc.gnu.org" , Jakub Jelinek , Segher Boessenkool , Peter Bergner , David Edelsohn References: <63b5434e-f8fa-97b3-d357-e25094579b16@netcologne.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: wlGKNGmyK25Hd348goV7sj7v87TETVOa X-Proofpoint-GUID: Hste5IrTrom0CmIm7qf3pH6ADeeaTJgW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-01_07,2021-11-01_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 impostorscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 malwarescore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111010099 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, 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, 01 Nov 2021 18:46:52 -0000 On Mon, Nov 01, 2021 at 10:54:27AM -0500, Bill Schmidt wrote: > Hi Thomas, > > To me this looks excellent.  If you feel that support for both forms is achievable, > that's certainly superior. We had previously been concerned about whether the > necessary name mangling support would be possible, but it sounds like you aren't > overly worried about that. > > I'll let Mike weigh in about using the same options as are present for C/C++, which > I think should be the right approach, but I know I don't know all the subtleties. > That would also help determine whether -freal-16=ibm is the right default. I think > it probably is, but I'll let those more familiar with the details weigh in. > > Thanks again! > Bill Lets see if I can describe the C/C++ side of things. Internally, we have 3 floating point types: * KFmode: IEEE 128-bit * IFmode: IBM 128-bit * TFmode: What long double maps to (either IEEE 128-bit or IBM 128-bit) In general, you should use TFmode if the 128-bit type matches long double, and only use IFmode/KFmode if you are using a 128-bit type that does not match long double. We support 3 keywords: * __float128: Historic keywork for IEEE 128-bit (both C/C++) * _Float128: IEEE 128-bit (from ISO/IEC TS 18661-‐3:2015, C only) * __ibm128: Keyword to access current IBM 128-bit. There are 2 naming conventions for 128-bit IEEE functions: * Libquadmath: Math functions end in 'q'. * ISO/IEC TS 18661-2:2015: Math functions end in 'f128'. While we still build libquadmath, the C/C++ compiler and Glibc no longer generate the 'q' names. Instead we use the new names that end in f128. Starting with glibc 2.34, the glibc library supports the f128 names on PowerPC 64-bit little endian systems. As far as I know, glibc does not not provide the f128 names for big endian systems. We do build libquadmath and those interfaces could be used (much like the x86_64 does), but you may get issues of whether you are using a 'q' or 'f128' function. With glibc 2.34 and beyond, math.h remaps all of the math functions from 'l' suffix to 'f128' suffix if long double is IEEE 128-bit. In addition, the PowerPC back end does this mapping for built-in functions if you call the function without including math.h. Hence if you build a toolchain that defaults to IEEE 128-bit long double, Fortran calls to these functions are mapped. I believe glibc only does the IEEE 128-bit mapping if either long double is IEEE 128-bit or: * __STDC_WANT_IEC_60559_FUNCS_EXT__ is defined. * __STDC_WANT_IEC_60559_TYPES_EXT__ might also need to be defined. However, not all of the math functions have built-in counterparts to the name. The compiler does not map these functions. The libstdc++ library also does this mapping, starting wtih GCC 11. While we typically talk of going between IBM and IEEE 128-bit long doubles, the PowerPC compiler actually has 3 long double variants: * -mabi=ieeelongdouble: Long double is IEEE 128-bit if long doubles are 128-bits. * -mabi=ibmlongdouble: Long double is IBM 128-bit if long doubles are 128-bits. * -mlong-double-64: Long double is 64-bits and the -mabi=ieeelongdouble and -mabi=ibmlongdouble are not used. The following macros are defined: * __LONG_DOUBLE_IEEE128__: if long doubles are IEEE 128-bit; * __LONG_DOUBLE_IBM128__: If long doubles are IBM 128-bit; * __LONG_DOUBLE_128__: If long doubles are 128-bits (either IBM or IEEE). The ELF object file uses .gnu_attribute #4 to encode the current long double format. This is only set if calls are made using long double types (note, it is somewhat buggy, and it misses things like using long double in the code, but not doing a call, and the bit for 64-bit long doubles gets set if you pass or return normal 64-bit doubles when the 64-bit long switch is set. The bits are: * 0x1: Hardware 32/64-bit floating point is used. * 0x2: Software 32/64-bit floating point is used. Note, this bit is not set if IEEE 128-bit is emulated (power8). * Bits 0x4 and 0x8 are a 2 bit field: * 0x4: 64-bit long doubles are passed and returned; * 0x8: IBM 128-bit long doubles are passed and returned; * 0xc: IEEE 128-bit long doubles are passed and returned. If you are building libraries that contain modules with multiple long double types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi' option, which silences the warning that you are switching long double types (if glibc is not 2.34 or newer). We may need to tweak -Wno-psabi for use with Fortran. For shared libraries, the linker complains if any of the modules in the library set .gnu_attribute #4 to a different value than the current modules. When building the glibc and libstdc++ libraries There are 3 configuration options to chose the long double type: * --with-long-double-format=ibm: Chooses IBM 128-bit long double; * --with-long-double-format=ieee: Chooses IEEE 128-bit long double; * --without-long-double-128: Choose 64-bit long double. While I have tried to minimize the differences in running the test suites, if you change the long double type, there will be changes in what tests pass or fail. * A lot of the C++ modules tests fail when you switch the long double type. * 3 Fortran tests that tradionally fail, actually pass now. * There are a bunch of tests that fail when long double is 64-bits. * There are 2 C tests that fail due to issues with signalling NaNs with explicit _Float128 support that fail if long double is IEEE 128. In order to build a toolchain that defaults to IEEE 128-bit long double (or 64-bit long double), I go through the following steps: * Build a standard toolchain (either stage1 or bootstrap); * Build gmp, mpfr, and mpc with that toolchain, using the appropriate long double option and the compiler built above. I disable building shared libraries of these functions. Even though the compiler does not call any long double function from these libraries, the libraries do define long double variants. * Build a stage1 compiler configured for the intended floating point type using the compiler built in the first step. * Using the stage1 compiler built in the third step, then build a bootstrap compiler. In theory, you can omit the stage1 build, but I found it easier to debug things using the stage1 build instead of bootstrap. With the hacks that I did last week, I suspect the path of least resistance to the users is make KIND=16 match the long double format, and then have both floating point modules in libgfortran. On one hand, I can certainly understand the position that long double should always be IEEE 128-bit and KIND=16, but again people are using the existing support and don't want their code to change. It would be nice if we could make Fortran switch long double types via command line (though in general, there are a lot of places that you run into when doing this switch, such as using third party libraries). It would also be nice if users could explicitly ask for the IEEE 128-bit type. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com