Hi Janus,
The patch is rather large, but most of it is just mechanical, due to
the fact that I added an extra argument to 'gfc_dep_compare_expr'. I
use this function to compare the string-length expressions of a
character-valued TBP and an overriding procedure (the standard
requires them to be equal).
This will likely introduce rejects-valid bugs. For example,
gfc_dep_compare_expr is not able to see that a+b+c equals c+b+a.
What you can do is to raise an error if gfc_dep_compare_expr returns
1 or -1, because then we can prove that the expressions are unequal.
For -2, we just don't know.
Inside 'gfc_dep_compare_expr' I had to add
a minor piece to correctly respect commutativity of the multiplication
operator (for the addition operator this was done already).
Good idea; maybe you can commit that separately.
The extra
argument controls whether we check variable symbols for equality or
just their names. For the overriding checks it is sufficient to check
for names, because the arguments of the overriding procedure are
required to have the same names as in the base procedure.
Could you explain for which cases this test is too strict?
It might also be interesting to see if gfc_are_identical_variables could
also be relaxed. Then again, we might get by if we don't treat
-2 from gfc_dep_compare_expr as an error.
Moreover I extended the type check in 'check_typebound_override' to
also check for correct rank, via 'compare_type_rank' instead of
'gfc_compare_types'. However, the former was local to interface.c, so
I made it public (and should probably also rename it to gfc_...), or
should one rather move 'check_typebound_override' to interface.c
itself? I think it fits in there pretty nicely. After all it is
checking the interfaces of overriding procedures.
Whatever you choose, please make sure that any global function is
prefixed with gfc_ .
Regards
Thomas
