[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand

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

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