This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3


On 08/03/2015 02:36 PM, Paul Richard Thomas wrote:
Dear Mikael,

Thanks for your green light!

I have been mulling over the trans-decl part of the patch and having
been wondering if it is necessary. Without optimization, private
entities can be linked to. Given the discussion concerning the
combination of submodules and private entities, I wonder if this is
not sufficient? Within submodule scope, an advisory could be given for
undefined references to suggest recompiling the module without
optimization or making the entities public.

Cheers

Paul

On 3 August 2015 at 12:44, Mikael Morin <mikael.morin@sfr.fr> wrote:
Le 29/07/2015 17:08, Paul Richard Thomas a Ãcrit :

Dear All,

On 24 July 2015 at 10:08, Damian Rouson <damian@sourceryinstitute.org>
wrote:

I love this idea and had similar thoughts as well.

:D

Sent from my iPhone

On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:

Dear Mikael,

It had crossed my mind also that a .mod and a .smod file could be
written. Normally, the .smod files are produced by the submodules
themselves, so that their descendants can pick up the symbols that
they generate. There is no reason at all why this could not be
implemented; early on in the development I did just this, although I
think that it would now be easier to modify this patch.

One huge advantage of proceeding in this way is that any resulting
library can be distributed with the .mod file alone so that the
private entities are never exposed. The penalty is that a second file
is output.

With best regards

Paul


Please find attached the implementation of this suggestion.

Bootstraps and regtests on FC21/x86_64 - OK for trunk or is the
original preferred?

There hasn't been a lot of voices about this among the other active and less
active team members.
I prefer this "private members to separate smod" variant.
It's OK for trunk as far as I'm concerned.
Thanks.

Mikael

PS: Regarding redundant initializations: rather have too many than too few.
;-)

Although I do not immediately know if this is relevant for *this* debate, J3 passed the following (attached) interpretation on submodules the past week (it still has to go to several mail ballots, but still), overwhelmingly prefering option 3:

[attached]

Kind regards,

--
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Attachment: 15-208.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]