[Bug fortran/41600] [OOP] SELECT TYPE with associate-name => exp: Arrays not supported

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

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