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