>> 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 guess that is just one way in which the things it usually does differ a bit from what I'm trying to do with it. Anyway, I think the tasks are reasonably similar to justify reusing gfc_dep_compare_expr instead of writing a new set of procedures, which would have to be of similar complexity. >> 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. Yes, if you want to express it in such a way. I'm know that this does not exactly fit in any of your categories. However, I still think that throwing an error for every case where we can not prove that the expressions are equal is a good approximation for the purpose, and everything beyond that is mostly academic. Firstly, string lengths of overridden type-bound procedures will probably never be extremely complicated expressions. Remember: The original bug report here was really just about *constant* string lengths, which is the most trivial and probably most frequent case. Second, it is easy for the programmer to lay out the expressions in analogous ways when overriding, so that gfc_dep_compare_expr is indeed able to prove they are equal. And third, in case there will really be any real-world problems with this, we can just wait for that bug report to roll in, and take care of the problem later (by refining gfc_dep_compare_expr's ability to prove two expressions are equal, e.g. by implementing more math transformations or similar things). Cheers, Janus
