This is the mail archive of the
mailing list for the GCC project.
[Bug fortran/25708] Module loading is not good at all
- From: "paul dot richard dot thomas at cea dot fr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 31 Oct 2006 08:29:37 -0000
- Subject: [Bug fortran/25708] Module loading is not good at all
- References: <email@example.com/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-10-31 08:29 -------
Subject: RE: Module loading is not good at all
> -----Message d'origine-----
> De : fxcoudert at gcc dot gnu dot org
> Envoyé : mardi 31 octobre 2006 08:01
> I like that idea. I've looked at the code in symbol.c, and
> don't see clearly
> how to get it done (where do you get the master symtree from, eg?)
I haven't really thought about this enough yet but.....
(i) I think that a namespace will have to be built for each module. This will
allow the initial part of read_module to be left completely unmodified. *grin*
(ii) The namespaces should be contained in a linked list or binary tree; the
structures should be something like
typedef struct gfc_module_namespace
const char *name;
struct gfc_module_namespace *next;
maybe some attributes?;
I think that a list should be sufficient, since numbers of modules are likely
to remain limited for real-life codes.... aren't they? Or is your 25Mb monster
an indication that I am wrong?
(iii) As the modules get USEd, new symtrees are added to the current namespace
and I think that it is OK to point to the symbols in the module namespaces.
This would simplify derived type association a lot. I have not the foggiest
idea what to do about interfaces; they are on my list of urgent things to try
to understand. I am about to create a meta-bug of interface PRs. I had a
notion to look at modules after I had had a stab at that.
(There is a PR on doubly USEd interfaces that I had a stab at in the airport
last Friday - I got absolutely nowhere; even though I thought that I was
touching the right places, it had no effect on the fault! This is one and the
same problem of doubly USEd variables that I fixed by explicitly going through
and checking each against the other. To do likewise for interfaces requires
some understanding! I note, however, that these problems are fixed in g95 and
there is no sign whatsoever of the corresponding fixes... It is a crying shame
that Andy Vaught is not on-side.)
(iv) As at present, the symtree carries the local name and the symbol the true
name - that's why I think that the symbols can be shared.
(v) Clearly, a clean-up at the end of the compilation of the file will have to
be done but all the mechanisms to do that exist already.
As I say, the problems are a) interfaces, b) interfaces and c) interfaces.