[Patch, Fortran] PR 66227: [5/6/7 Regression] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type

[Mikael Morin]

Le 16/11/2016 à 10:50, Janus Weil a écrit :
> Hi Mikael,
>
>>> Index: gcc/fortran/simplify.c
>>> ===================================================================
>>> --- gcc/fortran/simplify.c      (Revision 242447)
>>> +++ gcc/fortran/simplify.c      (Arbeitskopie)
>>> @@ -2517,7 +2517,7 @@ gfc_simplify_extends_type_of (gfc_expr *a, gfc_exp
>>>    if (UNLIMITED_POLY (a) || UNLIMITED_POLY (mold))
>>>      return NULL;
>>>
>>> -  /* Return .false. if the dynamic type can never be the same.  */
>>> +  /* Return .false. if the dynamic type can never be an extension.  */
>>>    if ((a->ts.type == BT_CLASS && mold->ts.type == BT_CLASS
>>>         && !gfc_type_is_extension_of
>>>                         (mold->ts.u.derived->components->ts.u.derived,
>>> @@ -2535,10 +2535,14 @@ gfc_simplify_extends_type_of (gfc_expr *a, gfc_exp
>>>        || (a->ts.type == BT_CLASS && mold->ts.type == BT_DERIVED
>>>           && !gfc_type_is_extension_of
>>>                         (mold->ts.u.derived,
>>> -                        a->ts.u.derived->components->ts.u.derived)))
>>> +                        a->ts.u.derived->components->ts.u.derived)
>>> +         && !gfc_type_is_extension_of
>>> +                       (a->ts.u.derived->components->ts.u.derived,
>>> +                        mold->ts.u.derived)))
>>>      return gfc_get_logical_expr (gfc_default_logical_kind, &a->where,
>>> false);
>>
>>
>> this doesn’t catch the case where «mold» is of a base type and «a» of
>> extended class.
>
> indeed the piece of code above does not catch the case you describe,
> but the piece that comes right after it in
> gfc_simplify_extends_type_of does. In this situation we have to
> simplify to a logical TRUE, because 'a' is guaranteed to be an
> extension of 'mold'. This corresponds to the case "(b11,a1)" in the
> test case.
>
>
>> I believe gfc_type_is_extension is misused here. The original code intended
>> meaning was probably that «a» is known not to be an extension of «mold», but
>> the negation of gfc_type_is_extension only gives that it’s not known to be,
>> which is weaker.
>
> I'm not fully sure what you mean here. These things have the tendency
> to tie a knot into my brain windings ;)
>
Nevermind. It was definitely time to go to bed when I wrote the above.


> On top of that comes the complication that the arguments of
> "gfc_type_is_extension_of" are in reversed order compared to
> EXTENDS_TYPE_OF :(
>
And it’s probably the actual bug. Your patch in the end is a sort of 
exchange of the arguments, isn’t it?

> In any case, I have thought about the logic of
> gfc_simplify_extends_type_of once again, and the only remaining
> problem I found was a case where the result was correct, but we missed
> some optimization, namely "(a1,b11)" in the test case. This was left
> as a runtime-case, but in fact it can be evaluated to FALSE at compile
> time.
>
> I fixed the simplification function and the test case accordingly, and
> hope that everything should be fine now. Right? (Updated patch
> attached ...)
>
Looks good to me. Thanks.

Mikael