http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41600
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-21
19:57:07 UTC ---
(Those comments are for the example in comment 1)
The ICE happens for:
integer :: X = -999.0
where one calls gfc_trans_scalar_assign with ts.type == BT_INTEGER and fold
convert fails to convert the constant 999.0 to an integer.
Without type spec, one uses the _vtab->__def_init while with type spec, one
directly assigns. That's toggled in resolve.c:7018 (resolve_allocate_expr).
With type spec, one has a call to gfc_default_initializer.
In principle, the FE should convert 999.0 into 999. This happens twice via
gfc_convert_type_warn, which is called via: resolve_types -> resolve_values ->
resolve_structure_cons. But seemingly there is still some loop whole where it
does not happen.
Draft:
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3776,3 +3782,8 @@ gfc_default_initializer (gfc_typespec *ts)
if (comp->initializer)
- ctor->expr = gfc_copy_expr (comp->initializer);
+ {
+ ctor->expr = gfc_copy_expr (comp->initializer);
+ if (comp->ts.type != comp->initializer->ts.type
+ || comp->ts.kind != comp->initializer->ts.kind)
+ gfc_convert_type_warn (ctor->expr, &comp->ts, 2, false);
+ }
* * *
OK, that fixed comment 1. But comment 0 still has issues:
a) As is, it fails at:
hfj3af.f90:1:0: internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.c:997
Breakpoint 1, gfc_conv_component_ref
997 gcc_assert (f2);
(gdb) p f2
$1 = (tree_node *) 0x0
#1 0x00000000005d484e in gfc_conv_variable (se=0x7fffffffd130, expr=0x16c4280)
at fortran/trans-expr.c:1238
#2 0x00000000005d4154 in gfc_conv_expr_val (se=0x7fffffffd130, expr=<optimized
out>) at fortran/trans-expr.c:5450
#3 0x00000000005ffb96 in gfc_trans_integer_select (code=<optimized out>) at
fortran/trans-stmt.c:1821
#4 gfc_trans_select (code=0x16cb9a0) at fortran/trans-stmt.c:2380
If one looks in gfc_conv_variable just before the ICEing gfc_conv_component_ref
at the values, one finds: One has an EXPR_VARIABLE ("bar") which points to
("ref") to _vptr->_hash. The issue already occurs for expr->ref where one has
in gfc_conv_component_ref:
991 tree f2 = c->norestrict_decl;
But that's NULL. If one sets f2 to c->backend_decl, one now iterates through f2
= DECL_CHAIN (f2), does not find the suitable field, and fails at the same
assert line.
b) If one comments the type is(t0) line and the print line, one gets a
segfault.
Invalid read of size 8
at 0x5ABD0B: gfc_conv_scalarized_array_ref(gfc_se*, gfc_array_ref*)
(trans-array.c:3016)
by 0x5AC7A1: gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_symbol*,
locus*) (trans-array.c:3112)
by 0x5D47B7: gfc_conv_variable(gfc_se*, gfc_expr*) (trans-expr.c:1230)
That's the line:
expr = ss->info->expr;
For some reason, this empty select type wants to get scalarized. The cally has:
/* Handle scalarized references separately. */
if (ar->type != AR_ELEMENT)
{
gfc_conv_scalarized_array_ref (se, ar);
