Go to file
Michael Meissner 3cf04d1afa 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  <meissner@linux.ibm.com>

	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.
2021-04-21 23:03:05 -04:00
c++tools
config Daily bump. 2021-04-14 00:16:24 +00:00
contrib Daily bump. 2021-04-21 00:16:23 +00:00
fixincludes
gcc Fix Fortran rounding issues, PR fortran/96983. 2021-04-21 23:03:05 -04:00
gnattools
gotools
include
INSTALL
intl Daily bump. 2021-04-17 00:16:25 +00:00
libada
libatomic
libbacktrace
libcc1
libcody
libcpp Daily bump. 2021-04-20 00:16:27 +00:00
libdecnumber
libffi
libgcc
libgfortran
libgo libgo: update to Go1.16.3 release 2021-04-12 15:23:16 -07:00
libgomp Daily bump. 2021-04-22 00:16:32 +00:00
libhsail-rt
libiberty Daily bump. 2021-04-22 00:16:32 +00:00
libitm
libobjc
liboffloadmic
libphobos Daily bump. 2021-04-22 00:16:32 +00:00
libquadmath
libsanitizer Daily bump. 2021-04-18 00:16:21 +00:00
libssp
libstdc++-v3 Daily bump. 2021-04-22 00:16:32 +00:00
libvtv
lto-plugin Daily bump. 2021-04-22 00:16:32 +00:00
maintainer-scripts Daily bump. 2021-04-21 00:16:23 +00:00
zlib
.dir-locals.el
.gitattributes
.gitignore
ABOUT-NLS
ar-lib
ChangeLog Daily bump. 2021-04-12 00:16:27 +00:00
ChangeLog.jit
ChangeLog.tree-ssa
compile
config-ml.in
config.guess
config.rpath
config.sub
configure
configure.ac
COPYING
COPYING3
COPYING3.LIB
COPYING.LIB
COPYING.RUNTIME
depcomp
install-sh
libtool-ldflags
libtool.m4
lt~obsolete.m4
ltgcc.m4
ltmain.sh
ltoptions.m4
ltsugar.m4
ltversion.m4
MAINTAINERS MAINTAINERS: Add myself for write after approval 2021-04-11 12:09:11 +01:00
Makefile.def
Makefile.in
Makefile.tpl
missing
mkdep
mkinstalldirs
move-if-change
multilib.am
README
symlink-tree
test-driver
ylwrap

This directory contains the GNU Compiler Collection (GCC).

The GNU Compiler Collection is free software.  See the files whose
names start with COPYING for copying permission.  The manuals, and
some of the runtime libraries, are under different terms; see the
individual source files for details.

The directory INSTALL contains copies of the installation information
as HTML and plain text.  The source of this information is
gcc/doc/install.texi.  The installation information includes details
of what is included in the GCC sources and what files GCC installs.

See the file gcc/doc/gcc.texi (together with other files that it
includes) for usage and porting information.  An online readable
version of the manual is in the files gcc/doc/gcc.info*.

See http://gcc.gnu.org/bugs/ for how to report bugs usefully.

Copyright years on GCC source files may be listed using range
notation, e.g., 1987-2012, indicating that every year in the range,
inclusive, is a copyrightable year that could otherwise be listed
individually.