This is the mail archive of the
gcc-bugs@gcc.gnu.org
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: 9 Jan 2006 07:36:58 -0000
- Subject: [Bug fortran/25708] Module loading is not good at all
- References: <bug-25708-6528@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-01-09 07:36 -------
Subject: RE: Module loading is not good at all
Andrew,
> ------- Comment #1 from pinskia at gcc dot gnu dot org
> 2006-01-07 05:10 -------
> Looking at the profile for PR 21130 makes me think fixing
> this bug will also
> fix that one.
> Oh. it is just as bad if we have module modulef declared in
> the same file as we
> have to save it and then reload it which is just a waste of time.
>
I have proposed to introduce module namespaces that are built just once per
compiled file per module; either from source or a mod file. Subsequent usage
can lift the symbol information from the appropriate namespace.
> To Paul:
> Also fixing up the derived types after the fact is just wrong
> that was PR
> 25391.
>
What makes you say that? We have a choice about the way that this should be
done:
(i) Catch equal derived types at the read_module + match stage;
(ii) At resolution; or
(iii) At the translation stage.
I came to the conclusion that (iii) was the most economical, in terms of code,
and the simplest to implement. There is nothing "wrong" in having separate
symbols for the same object in different scopes, just as long as the tree
declaration is the same.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708