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] |
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 iPhoneOn 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 PaulPlease 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] |