[Bug fortran/25708] Module loading is not good at all

["paul dot richard dot thomas at cea dot fr" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]



------- 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:gcc-bugzilla@gcc.gnu.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?;
}
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