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

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

[seurer at gcc dot gnu.org]

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

            Bug ID: 96983
           Summary: [11 regression] ICE compiling gfortran.dg/pr96711.f90
                    starting with r11-3042
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:9164caf25cb210ad0a69357b226e39913aff00d1, r11-3042 

make  -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/pr96711.f90"
FAIL: gfortran.dg/pr96711.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pr96711.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr96711.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/pr96711.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr96711.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/pr96711.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr96711.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gfortran.dg/pr96711.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr96711.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr96711.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr96711.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/pr96711.f90   -Os  (test for excess errors)
# of unexpected failures        12
# of unresolved testcases       12

Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr96711.f90   
-fdiagnostics-plain-output  -fdiagnostics-plain-output    -O3 -g 
-pedantic-errors -fdump-tree-original 
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
 -lm  -o ./pr96711.exe    (timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr96711.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -O3 -g -pedantic-errors
-fdump-tree-original
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./pr96711.exe
f951: internal compiler error: Could not find real kind with at least 128 bits
0x102465e3 gfc_report_diagnostic
        /home/seurer/gcc/git/gcc-test/gcc/fortran/error.c:782
0x10248643 gfc_internal_error(char const*, ...)
        /home/seurer/gcc/git/gcc-test/gcc/fortran/error.c:1402
0x103d1dc7 build_round_expr
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans-intrinsic.c:406
0x103d1dc7 build_fix_expr
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans-intrinsic.c:436
0x103d2023 gfc_conv_intrinsic_int
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans-intrinsic.c:566
0x103e35d3 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans-intrinsic.c:10171
0x103a52cb gfc_conv_function_expr
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans-expr.c:7547
0x103b551f gfc_trans_assignment_1
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans-expr.c:10903
0x10347467 trans_code
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans.c:1864
0x103905b3 gfc_generate_function_code(gfc_namespace*)
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans-decl.c:6865
0x1034df63 gfc_generate_code(gfc_namespace*)
        /home/seurer/gcc/git/gcc-test/gcc/fortran/trans.c:2214
0x102d34ab translate_all_program_units
        /home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6347
0x102d34ab gfc_parse_file()
        /home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6616
0x10342d4b gfc_be_parse_file
        /home/seurer/gcc/git/gcc-test/gcc/fortran/f95-lang.c:212

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

[anlauf at gcc dot gnu.org]

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.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0

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

[anlauf at gcc dot gnu.org]

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

[seurer at gcc dot gnu.org]

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

[seurer at gcc dot gnu.org]

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

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> 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 <ro at gcc dot gnu.org> ---
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=<tree 0x0>, arg=<optimized out>) 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=<tree 0x0>, arg=<optimized
out>) at /vol/gcc/src/hg/master/local/gcc/fold-const.c:2404
#1  0x0067606c in build_round_expr (restype=<integer_type 0xfb9f8600
integer(kind=16)>, arg=<var_decl 0xfa86bd90 x>) at
/vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
#2  build_fix_expr (pblock=0xffbfdde4, arg=<var_decl 0xfa86bd90 x>,
type=<integer_type 0xfb9f8600 integer(kind=16)>, op=<optimized out>) 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=<optimized out>, dealloc=<optimized out>, use_vptr_copy=<optimized
out>, may_alias=<optimized out>) at
/vol/gcc/src/hg/master/local/gcc/fortran/trans-expr.c:10908
#5  0x00605d98 in trans_code (code=0x1be8138, cond=<tree 0x0>) 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=<optimized out>, argv=<optimized out>)
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

[anlauf at gcc dot gnu.org]

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

[anlauf at gcc dot gnu.org]

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <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=<tree 0x0>, arg=<optimized out>)
    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 = <tree 0x0>
(gdb) up
#1  0x0067606c in build_round_expr (restype=
    <integer_type 0xfb9f8600 integer(kind=16)>, arg=<var_decl 0xfa86bd90 x>)
    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 = <tree 0x0>

> 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

[anlauf at gcc dot gnu.org]

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

--- 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?
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

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meissner at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org

--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> ---
(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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

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

[anlauf at gcc dot gnu.org]

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #12)
> 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

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <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 passes            18878
# of unexpected failures        16537
# 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

[bergner at gcc dot gnu.org]

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

--- Comment #15 from Peter Bergner <bergner at gcc dot gnu.org> ---
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

[bergner at gcc dot gnu.org]

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

--- Comment #16 from Peter Bergner <bergner at gcc dot gnu.org> ---
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

[bergner at gcc dot gnu.org]

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

--- Comment #17 from Peter Bergner <bergner at gcc dot gnu.org> ---
(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

[bergner at gcc dot gnu.org]

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

--- Comment #18 from Peter Bergner <bergner at gcc dot gnu.org> ---
(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

[anlauf at gcc dot gnu.org]

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

--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to ro@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

[segher at gcc dot gnu.org]

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

--- Comment #20 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #19 from anlauf at gcc dot gnu.org ---
> (In reply to ro@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

[joseph at codesourcery dot com]

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

--- Comment #22 from joseph at codesourcery dot com <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

[anlauf at gcc dot gnu.org]

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

--- Comment #23 from anlauf at gcc dot gnu.org ---
(In reply to joseph@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

[anlauf at gcc dot gnu.org]

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

[joseph at codesourcery dot com]

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

--- Comment #25 from joseph at codesourcery dot com <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

[segher at gcc dot gnu.org]

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

--- Comment #26 from Segher Boessenkool <segher at gcc dot gnu.org> ---
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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-10-03
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #27 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is thie PR fixed?

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #27 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

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

[seurer at gcc dot gnu.org]

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> 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 <ebotcazou at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #31 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:47403a0eefac52636db768dc46c3c88a2cd4b28e

commit r11-7595-g47403a0eefac52636db768dc46c3c88a2cd4b28e
Author: Eric Botcazou <ebotcazou@adacore.com>
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/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

[cvs-commit at gcc dot gnu.org]

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

--- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Michael Meissner <meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:3cf04d1afa8a4955a0a9a395dd21ce1b6484aa78

commit r12-54-g3cf04d1afa8a4955a0a9a395dd21ce1b6484aa78
Author: Michael Meissner <meissner@linux.ibm.com>
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  <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.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #34 from Tobias Burnus <burnus at gcc dot gnu.org> ---
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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #34 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> 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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3

commit r12-937-g9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3
Author: Tobias Burnus <tobias@codesourcery.com>
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #37 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Tobias Burnus
<burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:271fc1caac433e84e6389e73a5bf07350ea545e2

commit r11-8445-g271fc1caac433e84e6389e73a5bf07350ea545e2
Author: Tobias Burnus <tobias@codesourcery.com>
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

[burnus at gcc dot gnu.org]

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

--- Comment #38 from Tobias Burnus <burnus at gcc dot gnu.org> ---
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]
commit    r12-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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #39 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #40 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Michael Meissner
<meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:9baf563a176c4ea5a2a1606397ac09e16776d1ae

commit r11-9665-g9baf563a176c4ea5a2a1606397ac09e16776d1ae
Author: Michael Meissner <meissner@linux.ibm.com>
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  <meissner@linux.ibm.com>

    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

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #41 from Michael Meissner <meissner at gcc dot gnu.org> ---
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.