This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/46196] [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible


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

--- Comment #7 from janus at gcc dot gnu.org 2010-10-29 08:31:41 UTC ---
(In reply to comment #5)
> Meanwhile I am puzzled by the patch. My understanding of
> compare_type_rank and compare_type_rank_if is that these tests should be
> symmetric: test(A,B)==test(B,A). So if test(A,B)||test(B,A) changes something
> it means that the tests are actually asymmetric. This asymmetry seems buggy.

Well, this symmetry is exactly what the patch is about. For F95 derived types
the functions you mention are indeed symmetric (and they should be!). However,
for polymorphic arguments this symmetry no longer holds (cf.
gfc_type_compatible), because TYPE(t) (and all its extensions) are compatible
with CLASS(t) (e.g. you can pass an actual TYPE(t) argument to a CLASS(t)
formal), but not the other way around.

Now, for comparing specifics in a generic interface, one needs to symmetrize
this again by adding a call with switched arguments.


> Looking at gcc/fortran/interface.c, I see at lines 447 to 458:
> 
>       if (!(dt1->ts.type == BT_DERIVED && derived1 == dt1->ts.u.derived)
>             && !(dt1->ts.type == BT_DERIVED && derived1 == dt1->ts.u.derived)
>             && gfc_compare_types (&dt1->ts, &dt2->ts) == 0)
>         return 0;
> 
>       else if ((dt1->ts.type == BT_DERIVED && derived1 == dt1->ts.u.derived)
>                 && !(dt1->ts.type == BT_DERIVED && derived1 ==
> dt1->ts.u.derived))
>         return 0;
> 
>       else if (!(dt1->ts.type == BT_DERIVED && derived1 == dt1->ts.u.derived)
>                 && (dt1->ts.type == BT_DERIVED && derived1 ==
> dt1->ts.u.derived))
>         return 0;
> 
> Should not this be
> 
>       if (!(dt1->ts.type == BT_DERIVED && derived1 == dt1->ts.u.derived)
>             && !(dt2->ts.type == BT_DERIVED && derived2 == dt2->ts.u.derived)
>             && gfc_compare_types (&dt1->ts, &dt2->ts) == 0)
>         return 0;
> 
>       else if ((dt1->ts.type == BT_DERIVED && derived1 == dt1->ts.u.derived)
>                 && !(dt2->ts.type == BT_DERIVED && derived2 ==
> dt2->ts.u.derived))
>         return 0;
> 
>       else if (!(dt1->ts.type == BT_DERIVED && derived1 == dt1->ts.u.derived)
>                 && (dt2->ts.type == BT_DERIVED && derived2 ==
> dt2->ts.u.derived))
>         return 0;
> 
> ???

As already noted by Mikael, this piece of code is not important for this PR.
Still I guess you're right that it is bogus.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]