[Bug fortran/103158] New: ICE on arithmetic with type parameter

[Bug fortran/103158] New: ICE on arithmetic with type parameter

[b.j.braams at cwi dot nl]

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

            Bug ID: 103158
           Summary: ICE on arithmetic with type parameter
           Product: gcc
           Version: 10.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: b.j.braams at cwi dot nl
  Target Milestone: ---

(Different from Bug fortran/103154 reported a bit earlier, but perhaps
related.)

The following code triggers an internal compiler error. I believe that the code
is correct, and ice is anyway undesirable. Compilation proceeds fine if the
declaration expression x(0:n-1) is replaced by x(n), also fine if x(0:n) is
declared, but code triggers ice again for declaration x(2*n). Any arithmetic on
the length parameter n seems to trigger the ice.

Version information:
bash-5.0$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.1 20210422 (Red Hat 10.3.1-1) (GCC) 

Command line invocation for file Test.f90 and system response:
bash-5.0$ gfortran Test.f90
Test.f90:15:20:

   15 |   end subroutine foo
      |                    1
internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:3782
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

Content of file Test.f90:
bash-5.0$ cat Test.f90
module test
  implicit none
  private
  public :: foo
  type, public :: test_type (n)
     integer, len :: n = 0
     integer :: x(0:n-1)
  end type test_type
contains
  subroutine foo (k)
    integer, intent (in) :: k
    type (test_type(n=k)) :: tt0
    tt0%x = 0
    return
  end subroutine foo
end module test

[Bug fortran/103158] [PDT] ICE on arithmetic with type parameter

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE on arithmetic with type |[PDT] ICE on arithmetic
                   |parameter                   |with type parameter
           Priority|P3                          |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
Very likely a duplicate.

[Bug fortran/103158] [PDT] ICE on arithmetic with type parameter

[b.j.braams at cwi dot nl]

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

Bastiaan Braams <b.j.braams at cwi dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Bastiaan Braams <b.j.braams at cwi dot nl> ---
Yes (anlauf), this one appears to repeat the error report by kargl@gcc.gnu.org
on 2018-01-23, Bug 84008 - [PDT] ICE accessing kind and len parameters. In that
case too the offending code involves arithmetic on a length parameter, the
expression l1+1 in the type definition in 84008.

*** This bug has been marked as a duplicate of bug 84008 ***