Mikael Morin wrote:
Le 23/12/2012 15:29, Tobias Burnus a écrit :
Namely, I now simply only tag all the symbols which are written to the
.mod file. That way, there should be never a symbol which outside used
(no wrong-code issues).
Yeah, I thought about that too. But then, I was worried to have too
many things exported.
Before my patch (and hence in GCC up to 4.7), we export all module
procedures/module variables (and array parameters). Thus, we definitely
can not export more than in 4.7.
As some testing and the existing test cases show, we do not seem to
include unreachable symbols in the .mod file. If we still find a case,
where we do, we should fix module.c as it would also reduce the .mod
file size.
I admit without having looked at the .mod file, I was also not sure
whether (unreachable) private symbols could end up in the .mod file. I
also admit that the patch pointlessly marks, e.g., derived-type
declarations as public_used, but as no code generation is associated
with it, it doesn't matter.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK from my point of view, though I can't tell whether it is exactly
what we need or it's too big a hammer in some cases.
Well, if doesn't export anymore "myotherlen" for:
subroutine bar()
...
contains
function intern_func()
character(len=myotherlen()) :: intern_func
something which didn't work with my original patch as I couldn't
distinguish between using "myotherlen" as function result and in the
specification expression for a dummy argument of "bar". Thus, I had to
mark it as TREE_PUBLIC(). With the simple module.c patch, "myotherlen"
is no longer TREE_PUBLIC() as it should be.
Hence, the patch not only fixes the rejects-valid regression but it also
fixes a missed-optimization issue. Thus, the hammer should be be of the
ideal size.
Thanks for the review. I have committed it as Rev. 194706.
Tobias
PS: Merry Christmas to everyone!
