(j3.2006) (SC22WG5.5796) AW: Straw ballot on four small technical changes
John Reid
John.Reid
Fri Oct 28 11:43:32 EDT 2016
Reinhold,
Whoops! They should not be there. And the papers are 16-*, not 06-*.
Also they refer to Fortran 2015 not 2018. I am having a bad day.
Here is a corrected version. I am not supposed to change a WG5 document,
but I have not mounted it on the web yet and the changes are all at typo
level, so I will delay until tomorrow and then mount the corrected version.
John.
Bader, Reinhold wrote:
> Hello John,
>
> what is the meaning of the stars "(*)" that appear on the lines for 06-285r2 and 06-289?
>
> Cheers
> Reinhold
>
>> -----Urspr?ngliche Nachricht-----
>> Von: owner-sc22wg5 at open-std.org [mailto:owner-sc22wg5 at open-std.org]
>> Im Auftrag von John Reid
>> Gesendet: Freitag, 28. Oktober 2016 15:42
>> An: WG5 <sc22wg5 at open-std.org>
>> Betreff: (SC22WG5.5793) Straw ballot on four small technical changes
>>
>> WG5,
>>
>> We need to ballot on four small technical changes that were approved by
>> J3 at its recent meeting. This is very like votes we have had on interpretations
>> and I have allowed 28 days for voting.
>>
>> Cheers,
>>
>> John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N2119-1
WG5 straw ballot on technical changes
John Reid, 28 October 2016
This is a WG5 straw ballot on four technical changes to Fortran 2015
that were passed by J3 at its recent meeting. They are all very minor,
rather like interpretation changes, but they are technical changes and
are therefore outwith the authority of J3. This ballot is modeled on what
we do for for interpretations. They have been passed by J3 and need to be
approved by WG5.
The following changes are being balloted:
Yes No Paper Subject
--- --- 16-277r1 Allow C_SIZEOF for an assumed-rank array
--- --- 16-280r2 Allow cross-image access to violate aliasing rules
for coarray dummies
--- --- 16-285r2 Clarify ordering of finalisation w.r.t. deallocation
in assignment
--- --- 16-289 Additional prohibitions on pure procedures
The four J3 papers that contain the edits and discussions are appended.
Please mark the above -Y- in the Yes column for "yes", -C- in the Yes
column for "yes with comment", or -N- in the No column for a "no"
answer {be sure to include your reasons with "no"} and send to
sc22wg5 at open-std.org
by 0900 UK time on Friday, 25 November 2016, in order to be counted.
Thanks,
John.
.............................
J3/16-277r1
To: J3
From: Bill Long
Subject:
Date: 2016 October 11
Discussion:
In 8.5.8.7 Assumed-rank entity, C838 has limitations on what can be
done with assumed-rank objects. The list was expanded from the
initial version to allow assumed-rank arguments to intrinsic inquiry
functions. But now that we allow both BIT_SIZE() and SIZE(), it seems
reasonable to also allow C_SIZEOF from ISO_C_BINDING? The information
available from BIT_SIZE() and SIZE() are enough to compute C_SIZEOF().
I think this was probably an unintentional omission.
Edit to 16-007r2:
[107:16-17] In 8.5.8.7 Assumed-rank entity, in the second constraint
(C838), change "function C_LOC" to "functions C_LOC or C_SIZEOF".
.............................
To: J3 J3/16-280r2
From: R. Bader & Bill Long
Subject: coarray dummy arguments and aliasing rules
Date: 2016 October 13
References: 16-007r2, TS18508, 16-174
Introduction:
~~~~~~~~~~~~~
This paper is a rewrite of 16-174 that attempts to resolve a problem
with coindexed write accesses to dummy arguments. Paper 16-174 was
submitted to meeting 210 and had "no action".
Discussion:
~~~~~~~~~~~
Consider the following example program, to be executed with at least
2 images:
PROGRAM example_1
INTEGER :: a[*], il
il = this_image()
CALL sub(a, il)
CONTAINS
SUBROUTINE sub(b, il)
INTEGER :: b[*], il
SELECT CASE (this_image())
CASE (1)
b[2] = il ! (X)
SYNC ALL
CASE (2)
SYNC ALL
il = b ! (Y)
WRITE(*,*) il
CASE DEFAULT
SYNC ALL
END SELECT
END SUBROUTINE
END PROGRAM
Question 1A: Was it intended that the program example_1 is conforming?
Answer 1A: Yes, it is intended that this example is conforming. It
compiles with no errors and executes:
> ftn test.f90
> srun -n2 ./a.out
1
{It appears to me that this example currently is not conforming based
on the F2008 as well as 16-007r2 specifications, because the statement
marked (X) constitutes a violation of the anti-aliasing rule
16-007r2/15.5.2.13 para 1 item (3) on image 2: The object a on image
2 is modified through something else than image's 2 dummy argument.
If this reasoning is correct and the intent is for the program to
be conforming, edits are needed to fix the problem.}
Question 1B: Was it intended that the program example_1 is conforming
if statement (Y) is replaced by "il = a"?
Answer 1B: No, with this change the code would violate the
anti-aliasing rules.
{If the answer to 1A is "no", this question is of course trivial.}
Next, consider a second example program, again for at least 2 images:
PROGRAM example_2
USE, INTRINSIC :: iso_fortran_env
INTEGER(atomic_int_kind) :: a[*]=0, il
il = this_image()
SELECT CASE (this_image())
CASE (1)
CALL sub_1(a, il)
CASE (2)
CALL sub_2(a, il)
WRITE(*,*) il
END SELECT
CONTAINS
SUBROUTINE sub_1(b, il)
INTEGER(atomic_int_kind) :: b[*], il
CALL ATOMIC_DEFINE(b[2],il) ! (Z)
END SUBROUTINE
SUBROUTINE sub_2(b, il)
INTEGER(atomic_int_kind) :: b[*], il
il = 0
DO WHILE (il == 0)
CALL ATOMIC_REF(il, b)
END DO
END SUBROUTINE
END PROGRAM
Question 2: Was it intended that the program example_2 is conforming?
Answer 2: Yes, it is intended that this example is conforming. It
compiles with no errors and executes:
> ftn test2.f90
> srun -n2 ./a.out
1
{To my knowledge, the intent was that it should be possible to
coordinate actions between two procedures in the manner illustrated
by the code above. See also MR&C, Modern Fortran Explained, Section
19.6, last two paras. However, again the rule 16-007r2/15.5.2.13
para 1 item (3) appears to be violated, namely by statement (Z).}
Edits to 16-007r2:
------------------
[xix] Introduction, para 2, at the end of the bullet section Program
units and Procedures, append "A coarray dummy argument can be
referenced or defined by another image."
[324:14] In 15.5.2.13 Restrictions on entities associated with dummy
arguments, delete "or".
[324:16] In 15.5.2.13 Restrictions on entities associated with dummy
arguments, change the final "." to ", or".
[324:16+] In 15.5.2.13 Restrictions on entities associated with dummy
arguments, Add another item to (3):
"(d) the dummy argument is a coarray and the action is a coindexed
definition of the corresponding ultimate argument coarray from a
different image."
[324:24] In 15.5.2.13 Restrictions on entities associated with dummy
arguments, delete "or".
[324:26] In 15.5.2.13 Restrictions on entities associated with dummy
arguments, change the final "." to ", or".
[324:26+] In 15.5.2.13 Restrictions on entities associated with dummy
arguments, Add another item to (4):
"(d) the dummy argument is a coarray and the reference is a
coindexed reference of its corresponding ultimate argument coarray
from a different image."
[326:1-] At the end of 15.5.2.13 Restrictions on entities associated
with dummy arguments, After NOTE 15.40 add
"NOTE 15.40+1 The exception to the aliasing restrictions for dummy
coarrays enables cross-image access while the procedure is
executing. Because nonatomic accesses from different images
typically must be separated by an image control statement, code
optimization within segments is not unduly inhibited."
.............................
To: J3 Members J3/16-285r2
From: Van Snyder & Malcolm Cohen
Subject: Amendment to Interp F08/0013
References: 16-007r2, 16-257
Date: 2016 October 13
1. Introduction
===============
Interp F08/0013 introduced text that is in 7.5.6.3p1 "When finalization
occurs": "If the variable is an allocated allocatable variable that
would be deallocated by intrinsic assignment, the finalization occurs
before the deallocation."
This overlooked allocated allocatable ultimate components.
Finalization of an allocatable subobject during intrinsic assignment
needs to be clarified.
2. Edits to 16-007r2
====================
[xviii Introduction, under "Data usage and computation"] insert an item
"Finalization of an allocatable subobject during intrinsic assignment
has been clarified."
[84:29 7.5.6.3p1 "When finalization occurs"]
After "allocated allocatable variable"
insert ", or has an allocated allocatable subobject,",
making the whole paragraph read:
"When an intrinsic assignment statement is executed (10.2.1.3), if the
variable is not an unallocated allocatable variable, it is finalized
after evaluation of expr and before the definition of the variable.
If the variable is an allocated allocatable variable, or has an
allocated allocatable subobject, that would be deallocated by
intrinsic assignment, the finalization occurs before the
deallocation."
[84:32 7.5.6.3p2 "When finalization occurs"]
Replace "component" with "subobject", making the whole paragraph read:
"When a pointer is deallocated its target is finalized. When an
allocatable entity is deallocated, it is finalized unless it is the
variable in an intrinsic assignment statement or a subobject thereof.
If an error condition occurs during deallocation, it is processor
dependent whether finalization occurs."
.............................
J3/16-289
To: J3
From: Malcolm Cohen
Subject: Pure statement functions are too volatile
Date: 2016 October 12
1. Problems
Consider the following module:
Module m
Use Iso_C_Binding
Integer(C_int),Volatile :: vcount
Contains
Subroutine s(x)
Integer i,pure_stmtfn,x(:)
pure_stmtfn() = vcount
Forall (i=1:Size(x)) x(i) = pure_stmtfn()
End Subroutine
End Module
Statement function pure_stmtfn is pure because it references no
impure function. However, vcount may change at any time so this is
not actually pure. This was fixed for normal pure procedures by
Interp F03/0126, which prohibited the designator of a VOLATILE
variable from appearing within a pure subprogram. However, it did
not address statement functions.
Also, it appears that the following is valid, as long as the variable Z is
not used.
Pure Subroutine strange(y)
Integer,Intent(Out) :: y
Integer,Volatile :: z
y = 0
End Subroutine
Permitting Z to be declared, but not used, within STRANGE is strange.
2. Solution
Therefore we should do the same as F03/0126 for statement functions.
This will be a new incompatibility with Fortran 2003/8.
We should also fix this gratuitous strangeness with local volatiles.
It will also be a new incompatibility with Fortran 2003/8.
Note that we could address this via the interpretation process, but
given the timing, and especially since statement functions are
obsolescent, it seems simpler just to make the change to F2015.
3. Edits to 16-007r2
[30:30+] 4.3.3 Fortran 2008 compatibility, after p3,
insert new paragraph
"Fortran 2008 permitted a pure statement function to reference a
volatile variable, and permitted a local variable of a pure
subprogram or of a BLOCK construct within a pure subprogram to be
volatile (provided it was not used); this document does not permit
that."
{Incompatibility with Fortran 2008.}
[31:21+] 4.3.4 Fortran 2003 compatibility, after p9,
insert new paragraph
"Fortran 2003 permitted a pure statement function to reference a
volatile variable, and permitted a local variable of a pure
subprogram to be volatile (provided it was not used); this document
does not permit that.
{Incompatibility with Fortran 2003.}
[336:14] 15.7 Pure procedures, p1,
After "only pure functions"
insert "and does not contain the <designator> of a variable with
the VOLATILE attribute" (all in obsolescent font).
{Prohibit pure statement function from referencing a volatile variable.}
[336:29] same subclause, C1593,
between "not have the SAVE" and "attribute"
insert "or VOLATILE".
{Prohibit a local volatile variable in a pure subprogram.}
More information about the J3
mailing list