[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638

--- Comment #9 from janus at gcc dot gnu.org 2011-08-04 07:41:43 UTC ---
Hi Mikael,

> 4.5.7.3 (type-bound procedure overriding) has:
> â Either both shall be subroutines or both shall be functions having the same
> result characteristics (12.3.3).
> 
> 12.3.3 (Characteristics of function results):
> If a type parameter of a function result or a bound of a function result array
> is not a constant expression, the
> exact dependence on the entities in the expression is a characteristic
> 
> 
> So the standards asks for same-expression-ness.
> Whether a compiler should diagnose it is another question.

thanks for digging out these references. That makes it pretty clear.


> I understand reversed operands (for commutative operators) as having an equal
> "exact dependence on the entities". And same for associative operators. 
> Thus it is bound to be very complicated in the general case.

Yes, these are the kinds of things that I have also been worrying about. They
will complicate matters a bit, but I think one can handle it.


> About the functions to reuse there is also gfc_dep_compare_expr and its
> sub-functions (they should handle functions, variables and arithmetic
> operators).

Yes, Tobias already suggested this to me, and indeed it looks very much like
what we need here.


> I don't know however how you will have two corresponding dummy
> arguments (from different procedures) compare equal.

Well, the patch in comment #7 handles this by just comparing the names of the
arguments (which have to be the same in overridden procedures, so I this this
will be enough):

+    case EXPR_VARIABLE:
+      if (strcmp (e1->symtree->n.sym->name, e1->symtree->n.sym->name) != 0)
+    return FAILURE;


gfc_dep_compare_expr relies on a function called 'gfc_are_identical_variables'.
This really checks for equal symbols, which is too strict for our case here (so
we may add an extra argument to loosen this restriction?).

Thanks for the feedback ...