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 3C2D73948A51; Mon, 19 Apr 2021 18:55:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3C2D73948A51 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13JIXZgN182016; Mon, 19 Apr 2021 14:55:52 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 380d892rk4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Apr 2021 14:55:52 -0400 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 13JIXq8L182974; Mon, 19 Apr 2021 14:55:51 -0400 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 380d892rjr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Apr 2021 14:55:51 -0400 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 13JImeMh022097; Mon, 19 Apr 2021 18:55:50 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma02dal.us.ibm.com with ESMTP id 37yqaa13tt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Apr 2021 18:55:50 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 13JItnBn19530112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Apr 2021 18:55:50 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D2EDCB2066; Mon, 19 Apr 2021 18:55:49 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BA86DB2067; Mon, 19 Apr 2021 18:55:48 +0000 (GMT) Received: from ibm-toto.the-meissners.org (unknown [9.160.34.242]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTPS; Mon, 19 Apr 2021 18:55:48 +0000 (GMT) Date: Mon, 19 Apr 2021 14:55:47 -0400 From: Michael Meissner To: gcc-patches@gcc.gnu.org, Michael Meissner , Segher Boessenkool , David Edelsohn , Bill Schmidt , Peter Bergner , Will Schmidt , fortran@gcc.gnu.org, Janne Blomqvist , Tobias Burnus , =?iso-8859-1?Q?Fran=E7ois-Xavier?= Coudert , Jerry DeLisle , Erik Edelmann , Daniel Franke , Thomas =?iso-8859-1?Q?K=F6nig?= , Daniel Kraft , Toon Moene , Mikael Morin , Tobias =?iso-8859-1?Q?Schl=FCter?= , Paul Thomas , Janus Weil Subject: Fix Fortran rounding issues, PR fortran/96983. Message-ID: <20210419185547.GA24449@ibm-toto.the-meissners.org> Mail-Followup-To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Bill Schmidt , Peter Bergner , Will Schmidt , fortran@gcc.gnu.org, Janne Blomqvist , Tobias Burnus , =?iso-8859-1?Q?Fran=E7ois-Xavier?= Coudert , Jerry DeLisle , Erik Edelmann , Daniel Franke , Thomas =?iso-8859-1?Q?K=F6nig?= , Daniel Kraft , Toon Moene , Mikael Morin , Tobias =?iso-8859-1?Q?Schl=FCter?= , Paul Thomas , Janus Weil MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Eio1ZMWNypxpTy-Gt7AnC46BnPnKuzG2 X-Proofpoint-GUID: ISmL97cIwsfJR0YWLEAAgg9CBI7_ul7x X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-19_11:2021-04-19, 2021-04-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 suspectscore=0 adultscore=0 priorityscore=1501 clxscore=1011 lowpriorityscore=0 phishscore=0 spamscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104190126 X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_MANYTO, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 19 Apr 2021 18:56:07 -0000 Fix Fortran rounding issues, PR fortran/96983. I was looking at Fortran PR 96983, which fails on the PowerPC when trying to run the test PR96711.F90. The compiler ICEs because the PowerPC does not have a floating point type with a type precision of 128. The reason is that the PowerPC has 3 different 128 bit floating point types (__float128/_Float128, __ibm128, and long double). Currently long double uses the IBM extended double type, but we would like to switch to using IEEE 128-bit long doubles in the future. In order to prevent the compiler from converting explicit __ibm128 types to long double when long double uses the IEEE 128-bit representation, we have set up the precision for __ibm128 to be 128, long double to be 127, and __float128/_Float128 to be 126. Originally, I was trying to see if for Fortran, I could change the precision of long double to be 128 (Fortran doesn't access __ibm128), but it quickly became hard to get the changes to work. I looked at the Fortran code in build_round_expr, and I came to the conclusion that there is no reason to promote the floating point type. If you just do a normal round of the value using the current floating point format and then convert it to the integer type. We don't have an appropriate built-in function that provides the equivalent of llround for 128-bit integer types. This patch fixes the compiler crash. However, while with this patch, the PowerPC compiler will not crash when building the test case, it will not run on the current default installation. The failure is because the test is explicitly expecting 128-bit floating point to handle 10384593717069655257060992658440192_16 (i.e. 2**113). By default, the PowerPC uses IBM extended double used for 128-bit floating point. The IBM extended double format is a pair of doubles that provides more mantissa bits but does not grow the expoenent range. The value in the test is fine for IEEE 128-bit floating point, but it is too large for the PowerPC extended double setup. I have built the following tests with this patch: * I have built a bootstrap compiler on a little endian power9 Linux system with the default long double format (IBM extended double). The pr96711.f90 test builds, but it does not run due to the range of the real*16 exponent. There were no other regressions in the C/C++/Fortran tests. * I have built a bootstrap compiler on a little endian power9 Linux system with the default long double format set to IEEE 128-bit. I used the Advance Toolchain 14.0-2 to provide the IEEE 128-bits. The compiler was configured to build power9 code by default, so the test generated native power9 IEEE 128-bit instructions. The pr96711.f90 test builds and runs correctly in this setup. * I have built a bootstrap compiler on a big endian power8 Linux system with the default long double format (IBM extended double). Like the first case, the pr96711.f90 test does not crash the compiler, but the test fails due to the range of the real*16 exponent. There were no other regressions in the C/C++/Fortran tests. * I built a bootstrap compiler on my x86_64 laptop. There were no regressions in the tests. Can I check this change into the GCC trunk? I've not contributed to the Fortran front end before. If the maintainers like the patch, can somebody point out if I need to do additional things to commit the patch? gcc/fortran/ 2021-04-19 Michael Meissner PR gfortran/96983 * trans-intrinsic.c (build_round_expr): If int type is larger than long long, do the round and convert to the integer type. Do not try to find a floating point type the exact size of the integer type. --- gcc/fortran/trans-intrinsic.c | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index 5e53d1162fa..cceef8f34ac 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -386,30 +386,20 @@ build_round_expr (tree arg, tree restype) argprec = TYPE_PRECISION (argtype); resprec = TYPE_PRECISION (restype); - /* Depending on the type of the result, choose the int intrinsic - (iround, available only as a builtin, therefore cannot use it for - __float128), long int intrinsic (lround family) or long long - intrinsic (llround). We might also need to convert the result - afterwards. */ + /* Depending on the type of the result, choose the int intrinsic (iround, + available only as a builtin, therefore cannot use it for __float128), long + int intrinsic (lround family) or long long intrinsic (llround). If we + don't have an appropriate function that converts directly to the integer + type (such as kind == 16), just use ROUND, and then convert the result to + an integer. We might also need to convert the result afterwards. */ if (resprec <= INT_TYPE_SIZE && argprec <= LONG_DOUBLE_TYPE_SIZE) fn = builtin_decl_for_precision (BUILT_IN_IROUND, argprec); else if (resprec <= LONG_TYPE_SIZE) fn = builtin_decl_for_precision (BUILT_IN_LROUND, argprec); else if (resprec <= LONG_LONG_TYPE_SIZE) fn = builtin_decl_for_precision (BUILT_IN_LLROUND, argprec); - else if (resprec >= argprec && resprec == 128) - { - /* Search for a real kind suitable as temporary for conversion. */ - int kind = -1; - for (int i = 0; kind < 0 && gfc_real_kinds[i].kind != 0; i++) - if (gfc_real_kinds[i].mode_precision >= resprec) - kind = gfc_real_kinds[i].kind; - if (kind < 0) - gfc_internal_error ("Could not find real kind with at least %d bits", - resprec); - arg = fold_convert (gfc_get_real_type (kind), arg); - fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind); - } + else if (resprec >= argprec) + fn = builtin_decl_for_precision (BUILT_IN_ROUND, argprec); else gcc_unreachable (); -- 2.22.0 -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.ibm.com, phone: +1 (978) 899-4797