[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #31 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:47403a0eefac52636db768dc46c3c88a2cd4b28e commit r11-7595-g47403a0eefac52636db768dc46c3c88a2cd4b28e Author: Eric Botcazou Date: Wed Mar 10 12:05:53 2021 +0100 Do not assume that __float128 exists The code in build_round_expr implicitly assumes that __float128 exists, which is *not* the common case among 64-bit architectures since the "long double" type is generally already 128-bit for them. gcc/fortran/ PR fortran/96983 * trans-intrinsic.c (build_round_expr): Do not implicitly assume that __float128 is the 128-bit floating-point type.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
Target|powerpc64*-linux-gnu, |powerpc64*-linux-gnu,
|sparc*-sun-solaris2.11 |sparc*-*-*
CC||ebotcazou at gcc dot gnu.org
--- Comment #30 from Eric Botcazou ---
AFAICS the code implicitly assumes that __float128 exists, which is *not* the
common case among 64-bit architectures since "long double" is generally
128-bit.
Tentative fix for the SPARC at least:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 5c9258c65c3..ae359a07973 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -407,7 +407,10 @@ build_round_expr (tree arg, tree restype)
if (kind < 0)
gfc_internal_error ("Could not find real kind with at least %d bits",
resprec);
- arg = fold_convert (gfc_float128_type_node, arg);
+ if (gfc_real16_is_float128)
+ arg = fold_convert (gfc_float128_type_node, arg);
+ else
+ arg = fold_convert (long_double_type_node, arg);
fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind);
}
else
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #29 from seurer at gcc dot gnu.org --- Still showing up on powerpc64.
[Bug fortran/96983] [11 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 Priority|P3 |P4
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #27 from Dominique d'Humieres --- > Is thie PR fixed? Not at all: I'm still seeing it on sparc*-sun-solaris2.11, and there are tons of reports for other targets on gcc-testresults.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-10-03 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #27 from Dominique d'Humieres --- Is thie PR fixed?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #26 from Segher Boessenkool ---
What Joseph says in c#25. Also, the documentation currently says
The @code{KIND} value matches the storage size in bytes, [...]
which will have to change, too (the standard does not require this,
it is merely a convention, and it prevent having two REAL types of
size 16, as we need).
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #25 from joseph at codesourcery dot com --- On Mon, 14 Sep 2020, anlauf at gcc dot gnu.org wrote: > Remember that Fortran needs a correspondence between a storage representation > (in bytes / bits) and the kind type on the language side. We'd thus need a > method to get the machine mode for a given representation. If there are > multiple representations with the same storage size (ieee128 vs. ibm128), > the ME needs to provide a way to the FE to uniquely address those. What that suggests to me is having a target hook mapping a Fortran kind to a floating-point machine mode (or to one of the global tree nodes for floating-point types), alongside the target hook mapping a C type (float, double, long double) to a machine mode.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #24 from anlauf at gcc dot gnu.org --- I've submitted the patch in comment#19 for review: https://gcc.gnu.org/pipermail/fortran/2020-September/055079.html This would also change the affected testcase to include comment#2, and defer the issue for power*-*-*-
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #23 from anlauf at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #22) > Closely related: the LONG_DOUBLE_TYPE_SIZE target macro which assumes > "size in bits" can uniquely determine the format of long double. In the > absence of hacks such as the above, LONG_DOUBLE_TYPE_SIZE needs replacing > by a target hook that returns the machine mode, not "size in bits" (maybe > a hook that covers all of float, double and long double). Remember that Fortran needs a correspondence between a storage representation (in bytes / bits) and the kind type on the language side. We'd thus need a method to get the machine mode for a given representation. If there are multiple representations with the same storage size (ieee128 vs. ibm128), the ME needs to provide a way to the FE to uniquely address those.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #22 from joseph at codesourcery dot com --- On Fri, 11 Sep 2020, segher at gcc dot gnu.org wrote: > > #ifndef RS6000_MODES_H > > #define RS6000_MODES_H 1 > > #define FLOAT_PRECISION_IFmode 128 > > #define FLOAT_PRECISION_TFmode 127 > > #define FLOAT_PRECISION_KFmode 126 > > Yes, this is a useful hack, but it has its own problems; the underlying > problem *still* has to be fixed (namely, the assumption that if you have > two floating point modes, they are ordered such that any number in one of > the modes can be represented in the other. In reality no such ordering > exists: __ibm128 has values not representable in __ieee128, and vice versa). > > We do have two 16 byte floating point modes, and neither is "greater" than > the other. Closely related: the LONG_DOUBLE_TYPE_SIZE target macro which assumes "size in bits" can uniquely determine the format of long double. In the absence of hacks such as the above, LONG_DOUBLE_TYPE_SIZE needs replacing by a target hook that returns the machine mode, not "size in bits" (maybe a hook that covers all of float, double and long double).
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #19 from anlauf at gcc dot gnu.org --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) >> > --- Comment #13 from anlauf at gcc dot gnu.org --- >> > This may lead to a total mess, and I am unable to test it, but can you try: >> >> I just ran bootstraps on both sparc-sun-solaris2.11 and >> i386-pc-solaris2.11. x86 results are unchanged, but sparc is completely >> miserable: > > OK, thanks. Scrap the patch from comment#13. Let's try using long double > when TYPE_PRECISION (long_double_type_node) is big enough for the conversion: [...] > This should have no effect on x86. > > I may work on SPARC; could you please test for me? It did indeed: both sparc-sun-solaris2.11 and i386-pc-solaris2.11 bootstraps completed; the failures are gone and no regressions occured. Thanks. Btw., there's a Solaris/SPARC system in the GCC compile farm (gcc211), so you can test patches yourself if you like. It took me quite some time to do the testing myself this time because the regular weekly tests were still running on my system.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #20 from Segher Boessenkool --- (In reply to Peter Bergner from comment #18) > > Why aren't KFmode, IFmode and TFmode all 128??? Mike? > > This comes from rs6000-modes.h: > > /* We order the 3 128-bit floating point types so that IFmode (IBM 128-bit >floating point) is the 128-bit floating point type with the highest >precision (128 bits). This so that machine independent parts of the >compiler do not try to widen IFmode to TFmode on ISA 3.0 (power9) that has >hardware support for IEEE 128-bit. We set TFmode (long double mode) in >between, and KFmode (explicit __float128) below it. > >We won't encounter conversion from IEEE 128-bit to IBM 128-bit because we >don't have insns to support the IBM 128-bit aritmetic operations. */ > > #ifndef RS6000_MODES_H > #define RS6000_MODES_H 1 > #define FLOAT_PRECISION_IFmode 128 > #define FLOAT_PRECISION_TFmode 127 > #define FLOAT_PRECISION_KFmode 126 Yes, this is a useful hack, but it has its own problems; the underlying problem *still* has to be fixed (namely, the assumption that if you have two floating point modes, they are ordered such that any number in one of the modes can be represented in the other. In reality no such ordering exists: __ibm128 has values not representable in __ieee128, and vice versa). We do have two 16 byte floating point modes, and neither is "greater" than the other.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > --- Comment #13 from anlauf at gcc dot gnu.org ---
> > This may lead to a total mess, and I am unable to test it, but can you try:
>
> I just ran bootstraps on both sparc-sun-solaris2.11 and
> i386-pc-solaris2.11. x86 results are unchanged, but sparc is completely
> miserable:
OK, thanks. Scrap the patch from comment#13. Let's try using long double
when TYPE_PRECISION (long_double_type_node) is big enough for the conversion:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 32fe9886c57..c508a4faedb 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -395,6 +395,13 @@ build_round_expr (tree arg, tree restype)
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 == TYPE_PRECISION (long_double_type_node)
+ && resprec >= argprec)
+{
+ int kind = TYPE_PRECISION (long_double_type_node) / 8;
+ arg = fold_convert (long_double_type_node, arg);
+ fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind);
+}
else if (resprec >= argprec && resprec == 128)
{
/* Search for a real kind suitable as temporary for conversion. */
This should have no effect on x86.
I may work on SPARC; could you please test for me?
It will not work on POWER given comment#15 by Peter.
However, the prints by Peter suggest that IBM's long double could be a
usable type. So if this works on SPARC, one could adapt it to POWER,
but we'd need also a slightly adapted testcase that runs only on POWER,
while the original one is for IEEE128 platforms only.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #18 from Peter Bergner ---
(In reply to Peter Bergner from comment #17)
> const poly_uint16_pod mode_precision[NUM_MACHINE_MODES] =
> {
> ...
> { 4 * BITS_PER_UNIT }, /* SF */
> { 8 * BITS_PER_UNIT }, /* DF */
> { 126 }, /* KF */
> { 127 }, /* TF */
> { 128 }, /* IF */
> ...
>
> Why aren't KFmode, IFmode and TFmode all 128??? Mike?
This comes from rs6000-modes.h:
/* We order the 3 128-bit floating point types so that IFmode (IBM 128-bit
floating point) is the 128-bit floating point type with the highest
precision (128 bits). This so that machine independent parts of the
compiler do not try to widen IFmode to TFmode on ISA 3.0 (power9) that has
hardware support for IEEE 128-bit. We set TFmode (long double mode) in
between, and KFmode (explicit __float128) below it.
We won't encounter conversion from IEEE 128-bit to IBM 128-bit because we
don't have insns to support the IBM 128-bit aritmetic operations. */
#ifndef RS6000_MODES_H
#define RS6000_MODES_H 1
#define FLOAT_PRECISION_IFmode 128
#define FLOAT_PRECISION_TFmode 127
#define FLOAT_PRECISION_KFmode 126
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #17 from Peter Bergner ---
(In reply to Peter Bergner from comment #16)
> I don't know why gfc_real_kinds[2].mode_precision is 127, but I guess that
> is what is causing us to trigger the assert.
>
> When I tried adding -mfloat128 -mabi=ieeelongdouble to switch us to using
> IEEE128 as our long double type, I get the same
> gfc_real_kinds[2].mode_precision equal to 127. I'm not sure why. I don't
> know this code.
genmodes seems to create:
const poly_uint16_pod mode_precision[NUM_MACHINE_MODES] =
{
...
{ 4 * BITS_PER_UNIT }, /* SF */
{ 8 * BITS_PER_UNIT }, /* DF */
{ 126 }, /* KF */
{ 127 }, /* TF */
{ 128 }, /* IF */
...
Why aren't KFmode, IFmode and TFmode all 128??? Mike?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #16 from Peter Bergner --- I don't know why gfc_real_kinds[2].mode_precision is 127, but I guess that is what is causing us to trigger the assert. When I tried adding -mfloat128 -mabi=ieeelongdouble to switch us to using IEEE128 as our long double type, I get the same gfc_real_kinds[2].mode_precision equal to 127. I'm not sure why. I don't know this code.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #15 from Peter Bergner ---
On POWER, we see with an unpatched compiler, where long double == IBM double
double format:
(gdb) p gfc_float128_type_node
$16 = (tree) 0x0
(gdb) p gfc_real_kinds[0]
$17 = {epsilon = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = -22, _mpfr_d =
0x134f99d8}}, huge = {{_mpfr_prec = 24, _mpfr_sign = 1,
_mpfr_exp = 128, _mpfr_d = 0x134f9978}}, tiny = {{_mpfr_prec = 24,
_mpfr_sign = 1, _mpfr_exp = -125, _mpfr_d = 0x134f9998}},
subnormal = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = -148, _mpfr_d =
0x134f99b8}}, kind = 4, radix = 2, digits = 24,
min_exponent = -125, max_exponent = 128, range = 37, precision = 6,
mode_precision = 32, c_float = 1, c_double = 0,
c_long_double = 0, c_float128 = 0}
(gdb) p gfc_real_kinds[1]
$18 = {epsilon = {{_mpfr_prec = 53, _mpfr_sign = 1, _mpfr_exp = -51, _mpfr_d =
0x134f9a58}}, huge = {{_mpfr_prec = 53, _mpfr_sign = 1,
_mpfr_exp = 1024, _mpfr_d = 0x134f9a18}}, tiny = {{_mpfr_prec = 53,
_mpfr_sign = 1, _mpfr_exp = -1021, _mpfr_d = 0x134f99f8}},
subnormal = {{_mpfr_prec = 53, _mpfr_sign = 1, _mpfr_exp = -1073, _mpfr_d =
0x134f9a38}}, kind = 8, radix = 2, digits = 53,
min_exponent = -1021, max_exponent = 1024, range = 307, precision = 15,
mode_precision = 64, c_float = 0, c_double = 1,
c_long_double = 0, c_float128 = 0}
(gdb) p gfc_real_kinds[2]
$19 = {epsilon = {{_mpfr_prec = 106, _mpfr_sign = 1, _mpfr_exp = -104, _mpfr_d
= 0x134f9ad8}}, huge = {{_mpfr_prec = 106,
_mpfr_sign = 1, _mpfr_exp = 1023, _mpfr_d = 0x134f9a98}}, tiny =
{{_mpfr_prec = 106, _mpfr_sign = 1, _mpfr_exp = -968,
_mpfr_d = 0x134f9a78}}, subnormal = {{_mpfr_prec = 106, _mpfr_sign = 1,
_mpfr_exp = -1073, _mpfr_d = 0x134f9ab8}}, kind = 16,
radix = 2, digits = 106, min_exponent = -968, max_exponent = 1023, range =
291, precision = 31, mode_precision = 127, c_float = 0,
c_double = 0, c_long_double = 1, c_float128 = 0}
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from anlauf at gcc dot gnu.org --- > This may lead to a total mess, and I am unable to test it, but can you try: I just ran bootstraps on both sparc-sun-solaris2.11 and i386-pc-solaris2.11. x86 results are unchanged, but sparc is completely miserable: === gfortran Summary for unix === # of expected passes18878 # of unexpected failures16537 # of expected failures 177 # of untested testcases 1752 # of unresolved testcases 14688 # of unsupported tests 706 likewise with -m64. Most (all?) tests fail to link now, failing to find one or more of cabsq copysignq fmodq roundq sqrtq truncq e.g. FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single -O2 (test for excess errors) Excess errors: Undefined first referenced symbol in file cabsq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so fmodq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so sqrtq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so roundq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so truncq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so copysignq /var/gcc/regression/master/11.4-gcc-gas/build/sparc-sun-solaris2.11/./libgfortran/.libs/libgfortran.so ld: fatal: symbol referencing errors
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #12)
> Here's how the types align:
>
> kindmode_precision c_long_double c_float128
> x86 long double 10 80 1 0
> x86 __float128 16 128 0 1
> sparc long double 16 128 1 0
This may lead to a total mess, and I am unable to test it, but can you try:
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 26fdb2803a7..4d5de9066af 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -844,7 +844,14 @@ gfc_build_real_type (gfc_real_info *info)
if (mode_precision == DOUBLE_TYPE_SIZE)
info->c_double = 1;
if (mode_precision == LONG_DOUBLE_TYPE_SIZE)
-info->c_long_double = 1;
+{
+ info->c_long_double = 1;
+ if (mode_precision == 128)
+ {
+ info->c_float128 = 1;
+ gfc_real16_is_float128 = true;
+ }
+}
if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128)
{
info->c_float128 = 1;
It's likely to screw up power completely, but I don't have any feedback from
them.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
>> >> 0x67606b build_round_expr
>> >> /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
>> >
>> > That's:
>> >
>> > arg = fold_convert (gfc_float128_type_node, arg);
>> >
>> > Can you find out what gfc_float128_type_node is on SPARC,
>
>> 408arg = fold_convert (gfc_float128_type_node, arg);
>> (gdb) p gfc_float128_type_node
>> $2 =
>
> OK. Can you print kind which was determined a few lines before?
(gdb) p kind
$30 = 16
> Also, to find out why gfc_float128_type_node is NULL_TREE,
> can you investigate the array gfc_real_kinds?
>
> On x86, the supported kind values are 4,8,10,16, and
4, 8, 16 on sparc
> (gdb) p gfc_real_kinds[3]
> $9 = {epsilon = {{_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -111,
> _mpfr_d = 0x27ee628}}, huge = {{_mpfr_prec = 113, _mpfr_sign = 1,
> _mpfr_exp = 16384,
> _mpfr_d = 0x27ee5e8}}, tiny = {{_mpfr_prec = 113, _mpfr_sign = 1,
> _mpfr_exp = -16381, _mpfr_d = 0x27ee5c8}}, subnormal = {{_mpfr_prec =
> 113,
> _mpfr_sign = 1, _mpfr_exp = -16493, _mpfr_d = 0x27ee608}}, kind = 16,
> radix = 2,
> digits = 113, min_exponent = -16381, max_exponent = 16384, range = 4931,
> precision = 33,
> mode_precision = 128, c_float = 0, c_double = 0, c_long_double = 0,
> c_float128 = 1}
(gdb) p gfc_real_kinds[2]
$37 = {epsilon = {{_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -111,
_mpfr_d = 0x1baf2bc}}, huge = {{_mpfr_prec = 113, _mpfr_sign = 1,
_mpfr_exp = 16384, _mpfr_d = 0x1b9b31c}}, tiny = {{_mpfr_prec = 113,
_mpfr_sign = 1, _mpfr_exp = -16381, _mpfr_d = 0x1baf27c}}, subnormal = {{
_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -16493,
_mpfr_d = 0x1baf29c}}, kind = 16, radix = 2, digits = 113,
min_exponent = -16381, max_exponent = 16384, range = 4931, precision = 33,
mode_precision = 128, c_float = 0, c_double = 0, c_long_double = 1,
c_float128 = 0}
> In trans-types.c we have:
>
> if (gfc_real_kinds[index].c_float128)
> gfc_float128_type_node = type;
>
> Look in particular at the value of c_float128.
Not set for any of the 3 supported kinds.
>> I'd expect that's long double, which is IEEE128 on SPARC.
>
> So if it is IEEE128, where does the difference from x86 come from?
Here's how the types align:
kindmode_precision c_long_double c_float128
x86 long double 10 80 1 0
x86 __float128 16 128 0 1
sparc long double 16 128 1 0
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Peter Bergner changed: What|Removed |Added CC||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #11 from Peter Bergner --- (In reply to anlauf from comment #8) > There's apparently a real kind with mode_precision >= 128, > so we have to find out what it is, and if we can convert to it. To really confuse things, there are 2 16-byte float types on POWER. :-) Our old IBM double double format (__ibm128) and the newer IEEE128 format (__ieee128). We support using both types at the same time. Our "long double" type (is that what fortran uses?) is set to one of those types, depending on a configure time option (...and maybe a compile time option?).
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> >> 0x67606b build_round_expr
> >> /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
> >
> > That's:
> >
> > arg = fold_convert (gfc_float128_type_node, arg);
> >
> > Can you find out what gfc_float128_type_node is on SPARC,
> 408 arg = fold_convert (gfc_float128_type_node, arg);
> (gdb) p gfc_float128_type_node
> $2 =
OK. Can you print kind which was determined a few lines before?
Also, to find out why gfc_float128_type_node is NULL_TREE,
can you investigate the array gfc_real_kinds?
On x86, the supported kind values are 4,8,10,16, and
(gdb) p gfc_real_kinds[3]
$9 = {epsilon = {{_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -111,
_mpfr_d = 0x27ee628}}, huge = {{_mpfr_prec = 113, _mpfr_sign = 1,
_mpfr_exp = 16384,
_mpfr_d = 0x27ee5e8}}, tiny = {{_mpfr_prec = 113, _mpfr_sign = 1,
_mpfr_exp = -16381, _mpfr_d = 0x27ee5c8}}, subnormal = {{_mpfr_prec =
113,
_mpfr_sign = 1, _mpfr_exp = -16493, _mpfr_d = 0x27ee608}}, kind = 16,
radix = 2,
digits = 113, min_exponent = -16381, max_exponent = 16384, range = 4931,
precision = 33,
mode_precision = 128, c_float = 0, c_double = 0, c_long_double = 0,
c_float128 = 1}
In trans-types.c we have:
if (gfc_real_kinds[index].c_float128)
gfc_float128_type_node = type;
Look in particular at the value of c_float128.
> I'd expect that's long double, which is IEEE128 on SPARC.
So if it is IEEE128, where does the difference from x86 come from?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from anlauf at gcc dot gnu.org --- > (In reply to Rainer Orth from comment #6) >> The test also FAIL on 64-bit SPARC with an ICE/SEGV: >> >> 0x67606b build_round_expr >> /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408 > > That's: > > arg = fold_convert (gfc_float128_type_node, arg); > > Can you find out what gfc_float128_type_node is on SPARC, I find Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x008edab4 in fold_convert_loc (loc=0, type=, arg=) at /vol/gcc/src/hg/master/local/gcc/fold-const.c:2404 2404 if (TREE_CODE (arg) == ERROR_MARK (gdb) p gfc_float128_type_node $1 = (gdb) up #1 0x0067606c in build_round_expr (restype= , arg=) at /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408 408 arg = fold_convert (gfc_float128_type_node, arg); (gdb) p gfc_float128_type_node $2 = > and why the conversion fails? I've not the slightest idea how to do that. > There's apparently a real kind with mode_precision >= 128, > so we have to find out what it is, and if we can convert to it. I'd expect that's long double, which is IEEE128 on SPARC.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Rainer Orth from comment #6) > The test also FAIL on 64-bit SPARC with an ICE/SEGV: > > 0x67606b build_round_expr > /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408 That's: arg = fold_convert (gfc_float128_type_node, arg); Can you find out what gfc_float128_type_node is on SPARC, and why the conversion fails? There's apparently a real kind with mode_precision >= 128, so we have to find out what it is, and if we can convert to it.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Peter Bergner from comment #5) > (In reply to seurer from comment #3) > > That said, should the dg-require-effective-target fortran_real_16 "work" on > > powerpc64? > > REAL*16 is a 16 byte double, correct? Ie, our long double? Therefore, it > should exist and work too. The failure is: f951: internal compiler error: Could not find real kind with at least 128 bits Can you please list the table: gfc_real_kinds[i].mode_precision We're expecting a real kind with mode_precision >= 128. If "your" long double has less, how can I know?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Rainer Orth changed: What|Removed |Added Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||sparc*-sun-solaris2.11 CC||ro at gcc dot gnu.org Build|powerpc64*-linux-gnu| Host|powerpc64*-linux-gnu| --- Comment #6 from Rainer Orth --- The test also FAIL on 64-bit SPARC with an ICE/SEGV: Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/pr96711.f90:20:0: internal compiler error: Segmentation Fault 0xca67df crash_signal /vol/gcc/src/hg/master/local/gcc/toplev.c:327 0x8edab4 fold_convert_loc(unsigned int, tree_node*, tree_node*) /vol/gcc/src/hg/master/local/gcc/fold-const.c:2405 0x67606b build_round_expr /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408 0x67606b build_fix_expr /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:436 0x676257 gfc_conv_intrinsic_int /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:566 0x662867 gfc_trans_assignment_1 /vol/gcc/src/hg/master/local/gcc/fortran/trans-expr.c:10908 0x605d97 trans_code /vol/gcc/src/hg/master/local/gcc/fortran/trans.c:1864 0x641567 gfc_generate_function_code(gfc_namespace*) /vol/gcc/src/hg/master/local/gcc/fortran/trans-decl.c:6865 0x5a7e13 translate_all_program_units /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6347 0x5a7e13 gfc_parse_file() /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6616 0x60143f gfc_be_parse_file /vol/gcc/src/hg/master/local/gcc/fortran/f95-lang.c:212 $ f951 pr96711.f90 -mptr64 -mstack-bias -mno-v8plus -quiet -m64 -mcpu=v9 -O0 -fdump-tree-original -fintrinsic-modules-path finclude -o pr96711.s Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x008edab4 in fold_convert_loc (loc=0, type=, arg=) at /vol/gcc/src/hg/master/local/gcc/fold-const.c:2404 2404 if (TREE_CODE (arg) == ERROR_MARK (gdb) where #0 0x008edab4 in fold_convert_loc (loc=0, type=, arg=) at /vol/gcc/src/hg/master/local/gcc/fold-const.c:2404 #1 0x0067606c in build_round_expr (restype=, arg=) at /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408 #2 build_fix_expr (pblock=0xffbfdde4, arg=, type=, op=) at /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:436 #3 0x00676258 in gfc_conv_intrinsic_int (se=0xffbfdde4, expr=0x1be80a0, op=RND_ROUND) at /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:566 #4 0x00662868 in gfc_trans_assignment_1 (expr1=0x1be7ae0, expr2=0x1be80a0, init_flag=, dealloc=, use_vptr_copy=, may_alias=) at /vol/gcc/src/hg/master/local/gcc/fortran/trans-expr.c:10908 #5 0x00605d98 in trans_code (code=0x1be8138, cond=) at /vol/gcc/src/hg/master/local/gcc/fortran/trans.c:1864 #6 0x00641568 in gfc_generate_function_code (ns=0x1be52c8) at /vol/gcc/src/hg/master/local/gcc/fortran/trans-decl.c:6865 #7 0x005a7e14 in translate_all_program_units (gfc_global_ns_list=0x1be52c8) at /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6347 #8 gfc_parse_file () at /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6616 #9 0x00601440 in gfc_be_parse_file () at /vol/gcc/src/hg/master/local/gcc/fortran/f95-lang.c:212 #10 0x00ca69c8 in compile_file () at /vol/gcc/src/hg/master/local/gcc/toplev.c:457 #11 0x00ca9614 in do_compile () at /vol/gcc/src/hg/master/local/gcc/toplev.c:2314 #12 toplev::main (this=0xffbfe6b6, argc=, argv=) at /vol/gcc/src/hg/master/local/gcc/toplev.c:2453 #13 0x016dac70 in main (argc=14, argv=0xffbfe71c) at /vol/gcc/src/hg/master/local/gcc/main.c:39
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #5 from Peter Bergner --- (In reply to seurer from comment #3) > That said, should the dg-require-effective-target fortran_real_16 "work" on > powerpc64? REAL*16 is a 16 byte double, correct? Ie, our long double? Therefore, it should exist and work too.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #4 from seurer at gcc dot gnu.org ---
I see 6 other tests that use that:
gcc/testsuite/gfortran.dg/io_real_boz_3.f90:3:! { dg-require-effective-target
fortran_real_16 }
gcc/testsuite/gfortran.dg/io_real_boz_4.f90:3:! { dg-require-effective-target
fortran_real_16 }
gcc/testsuite/gfortran.dg/io_real_boz_5.f90:3:! { dg-require-effective-target
fortran_real_16 }
gcc/testsuite/gfortran.dg/nan_7.f90:3:! { dg-require-effective-target
fortran_real_16 }
gcc/testsuite/gfortran.dg/pr82253.f90:2:! { dg-do compile { target
fortran_real_16 } }
gcc/testsuite/gfortran.dg/pr96711.f90:3:! { dg-require-effective-target
fortran_real_16 }
gcc/testsuite/gfortran.dg/promotion_3.f90:3:! { dg-require-effective-target
fortran_real_16 }
Only nan_7.f90 is specifically skipped on powerpc and that is for another
reason as I recall.
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #3 from seurer at gcc dot gnu.org --- That changes it to unsupported which gets past the FAILs. That said, should the dg-require-effective-target fortran_real_16 "work" on powerpc64?
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #2 from anlauf at gcc dot gnu.org ---
Could you please check if adding
! { dg-skip-if "" { "powerpc*-*-*" } }
solves the issue? (That would be similar to testcase nan_7.f90)
[Bug fortran/96983] [11 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.0
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #1 from anlauf at gcc dot gnu.org ---
The testcase has:
! { dg-require-effective-target fortran_real_16 }
I assume that powerpc advertises supporting fortran_real_16
while it actually does not.
Suggestions?
Should the testcase be restricted to x86.
