Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

[Thomas Koenig <tkoenig@netcologne.de>]

Am 06.08.2011 21:26, schrieb Janus Weil:
> Hi Thomas,
>
>>> +      /* Check string length.  */
>>> +      if (proc_target->result->ts.type == BT_CHARACTER
>>> +&&    proc_target->result->ts.u.cl&&    old_target->result->ts.u.cl
>>> +&&    gfc_dep_compare_expr (proc_target->result->ts.u.cl->length,
>>> +                                  old_target->result->ts.u.cl->length) !=
>>> 0)
>>
>> This remains incorrect.
>
> well, I'm not so sure. If we assume a 'strict' interpretation of
> Mikael's standard quotes, then it would be ok.

I think that interpretation is wrong too, based on the leeway that
the standard gives in interpreting expressions.  a + b + c and
c + b + a are mathematically equivalent, and, right now, we cannot
prove them to be so.  (Yes, I would dearly like to do that, but
that is really hard based on the current gfc_expr format.  Instead
of parsing a + b + c as (+ (+ a b) c) like we do now, using (+ a b c)
which would make simplification much easier.  But the question is how
much we would gain from this vs. the effort :-).

Even hardline interpretation were correct, we are not even required to
diagnose this, because this is not a constraint.  The burden is on the
programmer, not the compiler writer.

I think it is most important to not reject correct programs.

>
>> Please change that to a warning (at least) if gfc_dep_compare_expr returns
>> -2.
>
> I don't think this is a good idea: gfc_dep_compare_expr also tries to
> determine whether one expr is larger or smaller than the other.
> Therefore the return value "-2" can have two meanings:
>
> 1) We don't know if the expressions are equal.
> 2) We know that they are unequal, but we don't know which one is larger.

Right now, we have the following cases (assuming the expressions to
be compared are a and b):

1 : We can prove that for all possible variable values, a > b
0 : We can prove that for all possible variable values, a = b
-1 : We can prove that all possible variable values, a < b
-2 : We cannot prove any of the above.

> For the overriding check, we don't care about which expr is larger, we
> want to know whether they are the same or not. So, in many cases we
> will just get a warning, although we definitely know that the expr's
> are different.
>
> Example: Differing expr_type, e.g. one procedure has len=3, the other
> has len=x. It's obvious they are different, but gfc_dep_compare_expr
> will still return "-2" (because we can not tell which one is larger).

In the context of what gfc_dep_compare_expr usually does, these 
expressions may be equal, because x may be 3.

> I would tend to leave the check like it is (i.e. rejecting everything
> !=0), but if you insist, one could extend the output values of
> gfc_dep_compare_expr, e.g. like this:
> -3 = we know nothing (neither if they could be equal, nor which one is larger)
> -2 = we know they are different, but not which one is larger

What you mean is that we should be able to prove that there
exists an x so that a != b.

If you can extend gfc_dep_compare_expr to prove this, great.  However,
for this, you must also handle a + b + c vs. c + b + a, i.e.
(+ (+ a b ) c) vs. (+ (+ c b) a).

> However, one may then have to modify the diagnostics on these return
> values in quite a few places(?).

I suspect that extending gfc_dep_compare_expr will be much more 
difficult than changing its calling sequence :-)

Regards

	Thomas