[Bug fortran/108872] New: ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment

[Bug fortran/108872] New: ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment

[trnka at scm dot com]

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

            Bug ID: 108872
           Summary: ICE in main_block_label, missing label when assigning
                    a derived type whose component has a defined
                    assignment
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trnka at scm dot com
  Target Milestone: ---

gfortran (tested versions 9 through 12.2.1 20221121) crashes when compiling the
following testcase because the "bb" pointer is null in main_block_label()
called from cleanup_dead_labels() in tree-cfg.c:

module TestModule

   implicit none
   private

   type :: A
      integer                        :: i = 0
   contains
      procedure   :: NewCopyOther
      generic     :: assignment(=) => NewCopyOther
   end type

   type :: B
      type(A)     :: aa
   end type

   type :: C
      type(B) :: x
   contains
      procedure :: Run
   end type

contains

   subroutine NewCopyOther(self, other)
      class(A), intent(out) :: self
      class(A), intent(in)  :: other

      self%i = other%i
   end subroutine

   subroutine Run(self)
      class(C), intent(inout) :: self

      type(B) :: y

      goto 2

    2 y = self%x

   end subroutine

end module

Apparently, the Fortran frontend never emits the "2" label as long as it's
placed on a line containing an assignment of a derived type (B) which has a
component with a defined assignment operator (A). The "original" dump for run()
looks like the following:

__attribute__((fn spec (". w ")))
void run (struct __class_testmodule_C_t & restrict self)
{
  struct b y;

  {
    struct b b.2;

    b.2.aa.i = 0;
    y = b.2;
  }
  goto __label_000002;
  y = self->_data->x;
  {
    struct __class_testmodule_A_t class.0;
    struct __class_testmodule_A_t class.1;

    class.0._vptr = (struct __vtype_testmodule_A * {ref-all})
&__vtab_testmodule_A;
    class.0._data = &y.aa;
    class.1._vptr = (struct __vtype_testmodule_A * {ref-all})
&__vtab_testmodule_A;
    class.1._data = &self->_data->x.aa;
    newcopyother (&class.0, &class.1);
  }
}

__label_000002 is thus used in a goto even though it's nowhere to be seen.

I guess bug 95613 might be related but probably not a duplicate as that one has
nothing to do with defined assignments.

[Bug fortran/108872] ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|                            |2023-02-21
     Ever confirmed|0                           |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  All gcc versions tested (>=7) fail.

Note that pr95613 is about invalid code, while the testcase in comment#0
appears to be valid Fortran.