Dear Paul,
Paul Richard Thomas wrote:
I am asking the question :-) Are the two equivalent? To my mind, it
is a matter of taste, if they are.
I think in practice they are the same. A derived-type entity with
parameter attribute ends up as static variable with TREE_READONLY. Thus,
within the same file (or with LTO) the middle end can do all kind of
fancy optimizations and in particular it can "devirtualize" function calls.
In principle, the FE could do replacements at compile time if one loads
a module with a derived-type parameter. However, I think the value is
not stored in the .mod file and hence, a module user in a different
translation unit would not be able to replace, e.g., the _vtable.size
information at compile time. And for methods (type-bound procedures), I
think it is basically impossible to do the compile-time replacement in
the FE. Thus, for the size or hash, I could imagine that PARAMETER has a
slight advantage - but only if we modify the information stored in the
.mod file.
Hence, with the current .mod information and (even with modified .mod)
with typical usage, the result should be the same.
(The only thing I am not quite sure is Janus' change to resolve.c, i.e.
whether it avoids re-running diagnostic checks [which is good] for
use-associated variables (known to be valid from the initial resolution)
or whether it can lead to a missing diagnostic [which would be bad].)
* * *
Regarding my patch: It is at least shorter, a single "|| attr.vtab". But
I don't have an opinion which patch is better. (All the work with the
VTAB flag and push_to_toplevel is unrelated to that issue, but should
also be solved at some point.)
Tobias
