http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |NEW
Resolution|FIXED |
--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-06
16:29:03 UTC ---
REOPEN.
The issue is mostly fixed (i.e. polymorphic operators work), but not
completely. As Dominique pointed out [1], the parentheses in
u = (u)*2.
still confuse gfortran (it works without).
Some preliminary analysis what goes wrong is available at [2, 3]:
a) In gfc_build_class_symbol, the attr->class_ok does not propagate to
fclass->attr.class_ok (should it?)
b) In matching_typebound_op, checking an EXPR_OP with
gfc_expr_attr (base->expr).class_ok fails - should on use
base->expr->ts->u.derived->attr.class_ok ?
c) In get_declared_from_expr (called by resolve_typebound_function):
The following is wrong (ice - segfault) for an EXPR_OP:
if (declared == NULL)
declared = e->symtree->n.sym->ts.u.derived;
should one use e->ts.u.derived?
(Regarding (base->expr,e)->ts.u.derived: I vaguely recall that sometimes e->ts
did not have the proper data and only e->symtree->n.sym->ts had. I don't recall
the details and it might have been only needed with some draft patch. It might
be that e->ts.u.derived was NULL, but it could have been also something
different.)
[1] http://gcc.gnu.org/ml/fortran/2012-01/msg00045.html
[2] http://gcc.gnu.org/ml/fortran/2012-01/msg00049.html
[3] http://gcc.gnu.org/ml/fortran/2012-01/msg00050.html
