[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Michael Meissner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #41 from Michael Meissner --- I tried applying the fix to the GCC 10 branch, and it appears that the patch needs more infrastructure needed. So, I'm closing the PR. If we need a GCC 10 backport, we can either reopen the issue or create a new bug report. It is fixed on the GCC 11 branch and on the master branch that will become GCC 12.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #40 from CVS Commits --- The releases/gcc-11 branch has been updated by Michael Meissner : https://gcc.gnu.org/g:9baf563a176c4ea5a2a1606397ac09e16776d1ae commit r11-9665-g9baf563a176c4ea5a2a1606397ac09e16776d1ae Author: Michael Meissner Date: Wed Mar 16 21:58:54 2022 -0400 Backport PR fortran/96983 patch to GCC 11. I applied a patch on the trunk in April 22nd, 2021 that fixes an issue (PR fortran/66983) where we could fail for 128-bit floating point types because we don't have a built-in function that is equivalent to llround for 128-bit integer types. Instead, the patch does a round operation followed by conversion to the appropriate integer size if we don't have the specialized round to specific integer type built-in functions. When I checked in the change, I was told to wait until after GCC 11.1 shipped before doing the backport. I forgot about the change until recently. Before checking it in, I did bootstraps and ran regression tests on: 1) little endian power9 using 128-bit IBM long double 2) little endian power9 using 128-bit IEEE long double 3) big endian power8 (both 64-bit and 32-bit) (and) 4) x86_64 native build There were no new regressions. The test gfortran.dg/pr96711.f90 now passes on PowerPC. In the 10 months or so since the change was made on the trunk, the code in build_round_expr did not change. 2022-03-16 Michael Meissner gcc/fortran/ PR fortran/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. Backport patch from 2021-04-22 on the trunk.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Richard Biener changed: What|Removed |Added Target Milestone|11.2|11.3 --- Comment #39 from Richard Biener --- GCC 11.2 is being released, retargeting bugs to GCC 11.3
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #38 from Tobias Burnus --- I think GCC 12/mainline is now fixed. The second patch was only applied to GCC 12 – it might need to be backported? (I have not checked GCC 11 with PowerPC.) (If there are remaining/new issues, I recommend to open a new PR.) Commits done: [For Sparc, I think] commit r11-7595, Eric Botcazou, Wed Mar 10 12:05:53 2021 +0100 Do not assume that __float128 exists [For PowerPC] commit r12-54, Michael Meissner, Wed Apr 21 23:02:07 2021 -0400 Fix Fortran rounding issues, PR fortran/96983. [Testcase only, for PowerPC] commitr12-937, Tobias Burnus, Thu May 20 09:51:10 2021 +0200 Backport: r11-8445 Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983]
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #37 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:271fc1caac433e84e6389e73a5bf07350ea545e2 commit r11-8445-g271fc1caac433e84e6389e73a5bf07350ea545e2 Author: Tobias Burnus Date: Thu May 20 09:51:10 2021 +0200 Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983] gcc/testsuite/ChangeLog: PR fortran/96983 * gfortran.dg/pr96711.f90: Use 2**digit(x) instead of a hard-coded value; add comments regarding what the code does. (cherry picked from commit 9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3)
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #36 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3 commit r12-937-g9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3 Author: Tobias Burnus Date: Thu May 20 09:51:10 2021 +0200 Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983] gcc/testsuite/ChangeLog: PR fortran/96983 * gfortran.dg/pr96711.f90: Use 2**digit(x) instead of a hard-coded value; add comments regarding what the code does.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #34 from Tobias Burnus --- > What's actually the status of the PR – I mean on both powerpc64*-linux-gnu, > sparc*-*-*. > > The summary states that there is an ICE – is this still the case? > I am especially interested in the sparc*-*-* status. Checking my test result logs, I find that the sparc failures are gone after 20210309. > If not, what remains to be done? > I assume that also some GCC 11 backporting is needed. AFAICS, this failure never existed on the gcc-11 branch on sparc.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #34 from Tobias Burnus --- What's actually the status of the PR – I mean on both powerpc64*-linux-gnu, sparc*-*-*. The summary states that there is an ICE – is this still the case? I am especially interested in the sparc*-*-* status. With powerpc64le-linux-gnu, I do not see an ICE anymore but two post-compilation FAILs for which I propose: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570732.html Does this also help for sparc*-*-* (and other powerpc64*-linux-gnu)? If not, what remains to be done? I assume that also some GCC 11 backporting is needed.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Jakub Jelinek changed: What|Removed |Added Target Milestone|11.0|11.2 --- Comment #33 from Jakub Jelinek --- GCC 11.1 has been released, retargeting bugs to GCC 11.2.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- 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 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. gcc/fortran/ 2021-04-21 Michael Meissner PR fortran/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.
