This is the mail archive of the 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]

Re: [Patch, Fortran] No-op Patch - a.k.a. FINAL wrapper update

Am 29.11.2012 23:51, schrieb Janus Weil:
one thing that I do not like about your patch is the modification of "gfc_find_derived_vtab": You create two versions of it, one of which creates the vtab if it does not exist, while the other version does not do this. [...] can you explain to me why this would be necessary?

Well, strictly speaking it is not necessary. However, I use it in the to-be-submitted calling part of the patch:

else if (al->expr->ts.type == BT_DERIVED)
gfc_symbol *vtab = gfc_find_derived_vtab (al->expr->ts.u.derived);
if (vtab)

Here, I do not want to force the generation of a vtab which wouldn't otherwise exist. Otherwise, one had to at least guard it by checks for nonextensible derived types (sequence, bind(C)).

[Moreover, the problem is that your new "gfc_find_derived_vtab" behaves different from the old one but has the same name, while your new "gfc_get_derived_vtab" behaves like the old "gfc_find_derived_vtab".

That's because of the bad choice of the current name. The other "find" functions do not generate the symbol if it does not exist, the "get" functions do. But otherwise I concur that changing the name is confusing.

Therefore, the places where you change the behavior by keeping the call to "gfc_find_derived_vtab" are not visible in the patch.

That should not happen. When I created the patch, I first renamed all existing versions, though it seems as if I there are currently three new ones which the current patch misses.

However, if you insist on the current meaning, can you provide a good name? Otherwise, I could use gfc_really_find_derived_vtab ;-)


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