[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021

["burnus at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #1 from burnus at gcc dot gnu dot org  2010-07-27 09:49 -------
Reduced test case:
!------------------------------------------------------------------
module iso_red
  type, public :: varying_string
     character(LEN=1), dimension(:), allocatable :: chars
  end type varying_string
end module iso_red

module ifiles
  use iso_red, string_t => varying_string
contains
  function line_get_string_advance (line) result (string)
    type(string_t) :: string
    character :: line
  end function line_get_string_advance
end module ifiles

module syntax_rules
  use iso_red, string_t => varying_string
  use ifiles, only: line_get_string_advance
contains
  subroutine syntax_init_from_ifile ()
    type(string_t) :: string
       string = line_get_string_advance ("")
  end subroutine syntax_init_from_ifile
end module syntax_rules
end
!------------------------------------------------------------------

The ICE occurs for:
  gfc_trans_assignment (trans-expr.c:5561)
    gfc_trans_assignment_1 (trans-expr.c:5419)
      gfc_trans_scalar_assign (trans-expr.c:4909)
       fold_convert_loc (fold-const.c:2021)

The fancy_abort occurs because TREE_CODE (type) is gcc_unreachable, type is the
second argument. The call is:
      gfc_add_modify (&block, lse->expr,
                           fold_convert (TREE_TYPE (lse->expr), rse->expr));
Namely "TREE_TYPE (lse->expr)" as "location_t" is added as first via #define.

Hereby LHS is variable "string" and RHS is function "line_get_string_advance".
Both have the same type: expr1->ts.u.derived->name == "varying_string" and
point to the _same_ expr2->ts.u.derived->backend_decl.

However, the data type looks different at TREE_TYPE, i.e.
    lse->expr.common.type != rse->expr.common.type

My working theory is that one generates a different back-end decl for
type(varying_string) and type(string_t).

However, ts.u.derived->backend_decl is the same - and as
ts.type.derived->components{,->ts.u.cl}->backend_decl is the same, I am not
sure whether this theory is correct.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077