From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6334C3835407; Thu, 22 Apr 2021 03:03:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6334C3835407 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042 Date: Thu, 22 Apr 2021 03:03:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 03:03:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96983 --- Comment #32 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:3cf04d1afa8a4955a0a9a395dd21ce1b6484aa78 commit r12-54-g3cf04d1afa8a4955a0a9a395dd21ce1b6484aa78 Author: Michael Meissner Date: Wed Apr 21 23:02:07 2021 -0400 Fix Fortran rounding issues, PR fortran/96983. I was looking at Fortran PR 96983, which fails on the PowerPC when tryi= ng to run the test PR96711.F90. The compiler ICEs because the PowerPC does n= ot 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/_Float= 128, __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 type= s to long double when long double uses the IEEE 128-bit representation, we h= ave 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 jus= t do a normal round of the value using the current floating point format and t= hen 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 float= ing point. The IBM extended double format is a pair of doubles that provid= es 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 Power= PC 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 t= he 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 compil= er 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 sys= tem with the default long double format (IBM extended double). Like the fi= rst case, the pr96711.f90 test does not crash the compiler, but the te= st 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. gcc/fortran/ 2021-04-21 Michael Meissner PR fortran/96983 * trans-intrinsic.c (build_round_expr): If int type is larger t= han 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.=