[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to ro@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 = <tree 0x0>
>
> 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:

                        kind    mode_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