[Patch, Fortran, OOP] PR 50960: vtables not marked as constant

Tobias Burnus burnus@net-b.de
Tue Nov 8 21:56:00 GMT 2011


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



More information about the Fortran mailing list