------- 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
FX > -----Message d'origine----- > De : fxcoudert at gcc dot gnu dot org > [mailto:[EMAIL PROTECTED] > 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?; } gfc_module_namespace; 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. Regards Paul (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. Ciao Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
