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.mo...@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 <dam...@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.tho...@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: t...@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
J3/15-208
To: J3
From: Malcolm Cohen
Subject: Interp of USE and submodules
Date: 2015 August 06
1. Introduction
Three options are provided for the answer to this interp:
Option 1: Basically what the actual text of the standard says now.
Accessing a PROTECTED item by a USE statement will hide the
host association, and therefore the item will be protected.
Option 2: Continue to allow a submodule to USE its ancestor, but say
that PROTECTED has no effect in this case.
Option 3: Decide that it was a mistake to allow a submodule to access
its ancestor module by use association, and forbid it.
2. The interpretation request
----------------------------------------------------------------------
NUMBER: F08/0128
TITLE: Is recursive USE within a submodule permitted?
KEYWORDS: SUBMODULE, USE
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress
QUESTION:
Consider
Module m1
Real x
End Module
Submodule(m1) subm1
Use m1
End Submodule
Q1. The module m1 is referenced from within one of its own
submodules. Is this standard-conforming?
Note that the "submodule TR", Technical Report 19767 contains, an edit
with the normative requirement:
"A submodule shall not reference its ancestor module by use
association, either directly or indirectly."
along with a note which says
"It is possible for submodules with different ancestor modules to
access each other's ancestor modules by use association."
It also contains an edit to insert the direct reference prohibition
as a constraint.
However, none of this text appears in ISO/IEC 1539-1:2010.
The Introduction simply comments that submodules are available, but
not that they have been extended beyond the Technical Report that
created them.
Also, consider
Module m2
Real, Private :: a
Real, Protected :: b
...
End Module
Submodule(m2) subm2
Contains
Subroutine s
Use m2
Implicit None
a = 3
b = 4
End Subroutine
End Submodule
In submodule SUBM2, procedure S references M2 by use association.
Use association does not make "A" accessible.
Q2. Is "A" still accessible by host association?
Also, procedure S attempts to assign a value to B, which is accessed
by use association, but has the PROTECTED attribute. Normally, this
attribute prevents assignment to variables accessed by use
association.
Q3. Is the assignment to "B" standard-conforming?
DISCUSSION:
The requirement appears in the early drafts of Fortran 2008, up to
08-007r1, then it was modified by paper 08-154r1 creating a UTI
(because the modification was broken), and finally the requirement was
completely removed by paper 09-141.
ANSWER OPTION 1:
A1. Yes, the example is conforming. An edit is supplied to add this
extension to the Introduction, and to add normative text to clause
11 to make this completely unambiguous.
A2. Yes, A is still accessible by host association.
Subclause 16.5.1.4 paragraph 2 states
"If an entity that is accessed by use association has the same
nongeneric name as a host entity, the host entity is
inaccessible by that name."
This does not apply since A is not being accessed by use
association (because it is PRIVATE), therefore A can still be
accessed by host association.
{J3 note: no edit necessary here.}
A3. No, the assignment to B is not conforming as it violates
constraint C551 which states
"A nonpointer object that has the PROTECTED attribute and is
accessed by use association shall not appear in a variable
definition context..."
An edit is provided to add an explanation of this.
ANSWER OPTION 2:
A1. Yes, the example is conforming. An edit is supplied to add this
extension to the Introduction, and to add normative text to clause
11 to make this completely unambiguous.
A2. Yes, A is still accessible by host association.
Subclause 16.5.1.4 paragraph 2 states
"If an entity that is accessed by use association has the same
nongeneric name as a host entity, the host entity is
inaccessible by that name."
This does not apply since A is not being accessed by use
association (because it is PRIVATE), therefore A can still be
accessed by host association.
{J3 note: no edit necessary here.}
A3. The assignment to B was intended to be conforming.
An edit is provided to correct constraint C551 to permit this.
ANSWER OPTION 3:
A1. No, the example was not intended to be conforming. Permission for
a submodule to access its ancestor module by use associated was a
mistake. An edit is provided to correct this error.
A2. Moot.
A3. Moot.
EDITS OPTION 1:
[xv] Introduction, p2, first bullet,
After "Submodules provide ... for modules."
Insert new sentence
"A submodule can reference its ancestor module by use
association."
[100:12] 5.3.15 PROTECTED attribute, insert this text immediately after
the word "descendants" (i.e. before the comma)
"where it is accessed by host association".
[272:23] 11.2.2 The USE statement and use association, p1,
After
"A module shall not reference itself, either directly or
indirectly."
Append to paragraph
"A submodule is permitted to reference its ancestor module by
use association. "
[273:2+4] Same subclause, NOTE 11.7, append
"If a submodule accesses a PROTECTED entity from its ancestor
module by use association, use of that entity is constrained by
the PROTECTED attribute, e.g. if it is not a pointer it cannot
appear in a variable definition context.".
EDITS OPTION 2:
[xv] Introduction, p2, first bullet,
After "Submodules provide ... for modules."
Insert new sentence
"A submodule can reference its ancestor module by use
association."
[100:6] 5.3.15 PROTECTED attribute, C551,
After "and is accessed by use association"
insert "from a scoping unit that is not within a submodule
of the module containing the definition of the
PROTECTED entity"
{Remove PROTECTED effect from ancestor module variables.}
[100:9] same subclause, C552,
same edit.
{Remove PROTECTED effect from ancestor module pointers.}
[272:23] 11.2.2 The USE statement and use association, p1,
After
"A module shall not reference itself, either directly or
indirectly."
Append to paragraph
"A submodule is permitted to reference its ancestor module by
use association. "
EDITS OPTION 3:
[275:9+] 11.2.3 Submodules,
"A submodule shall not reference its ancestor module by
use association, either directly or indirectly."
{NOTE TO J3: This could be inserted at [272:23] if that is thought
to be a better place.}
SUBMITTED BY: Malcolm Cohen
HISTORY: 15-134 m206 F08/0128 submitted
15-134r1 m206 Revised edits - passed by J3 meeting
15-187 m207 Failed J3 letter ballot 15-159
15-nnn m207 Revised with 3 options
----------------------------------------------------------------------
