(j3.2006) (SC22WG5.4751) Provisional result of interpretations ballot 3, N1933
John Reid
John.Reid
Sun Sep 2 11:58:34 EDT 2012
WG5,
Here is the provisional result of interpretations ballot 3, N1933.
Please let me know by 9 a.m. Weds (UK time) if I have omitted our ballot
or made an error in copying it.
Cheers,
John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N1939-1
Result of the interpretations ballot 2, N1933
Key for the Result line:
Y vote passes unconditionally.
C vote passes, subject to J3 considering the comments and reasons
and making no change that alters the technical content.
N vote fails. Returned to J3 for further work.
No result for F08/0040 is given here because it should not have been in N1933.
It is not included in N1932. The comments are given in alphabetic order, which
sometimes causes forward references to later comments.
F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/ F03/
0017 0018 0019 0021 0046 0053 0065 0084 0096 0103
Bader Y Y Y Y Y N Y N Y Y
Chen Y Y Y Y Y Y Y Y Y N
Cohen Y Y Y Y Y Y Y Y Y Y
Corbett Y Y Y Y Y N C N Y Y
Long Y Y Y Y Y N Y N Y Y
Maclaren Y Y Y Y Y C N C Y -
Muxworthy Y Y Y Y Y Y N N Y Y
Reid Y Y Y Y Y N Y N Y Y
Snyder Y Y Y Y Y Y Y N Y Y
Result Y Y Y Y Y N N N Y C
F03/ F03/ F03/ F03/ F08/ F08/ F08/ F08/ F08/ F08/
0116 0118 0120 0121 0004 0008 0031 0032 0038 0042
Bader Y Y Y N Y Y Y C Y Y
Chen Y Y Y Y Y Y Y Y Y Y
Cohen Y Y Y Y Y Y Y Y Y Y
Corbett Y Y Y N N C Y Y Y Y
Long Y Y Y N Y Y Y Y Y Y
Maclaren Y Y Y C Y Y Y Y Y Y
Muxworthy Y Y Y C Y Y Y Y Y Y
Reid Y Y Y N Y Y Y Y Y Y
Snyder Y Y C N Y Y Y Y Y Y
Result Y Y C N C C Y C Y Y
Comments and reasons for NO votes
F03/0053
Bader NO vote:
I agree with John Reid that it should be explicitly stated that
the above types do not have the BIND attribute.
Corbett NO vote:
I agree with John that allowing private components in
derived types that have the BIND attribute seems absurd.
Long NO vote:
Regarding answer 3, I think it would be better to disallow
PRIVATE components in a type with the BIND attribute. A C routine
called outside the module where the type is defined, and accessing a
variable of such a type would be able to access and modify the PRIVATE
components.
Maclaren comment:
A better solution would be to state that, notwithstanding the general
rules for derived types, they do have the BIND attribute and are
interoperable with C variables of type 'void *' and 'void (*) ()',
respectively. This matter should be addressed in a future revision, but
it might be easier to do that now than make the current situation
consistent.
I also agree with John Reid on question (2), and regard the liberty to
break the privacy restrictions by using interoperability as a defect in
the standard. And, yes, I agree that it would be fine to do that for
SEQUENCE, too. But both would be changes to the standard.
Reid NO vote:
1. I remain of the opinion that 15.3.3 should state clearly that
C_PTR and C_FUNPTR do not have the BIND attribute. It is counter-
intuitive that they are interoperable and yet do not have the
BIND attribute. They are defined in an intrinsic module so
the reader cannot look at the definition. The present text relies
on the distinction between "derived type" in 15.3.3 and "Fortran
derived type" in 15.3.4. The term "Fortran derived type" is
undefined and is not used anywhere else in the standard (as far
as I can see). The text of 15.3.3 is similar to 15.2.2 in the
Fortran 2003 standard. In N1622, J3 thought it was unclear and
proposed editing 15.2.2 to say that these types do have the BIND
attribute. I suggest the edit:
[431:2] 15.3.3, para 1. At the end of sentence 1 add
"and without the BIND attribute".
2. Was it really intended that a user-defined derived type with
the BIND attribute be permitted to have private components?
It seems to me that this should not be permitted since it
destroys the purpose of declaring components to be private.
If it was intended, the rationale should be included in the
answer - this is, after all, an interpretation.
....................................................................
F03/0053: Replies from the editor
- it is a fundamental principle that entities only have the attributes that
the standard says they have. We do not say the integer 13 does not have the
BIND attribute. We do not even say that derived types defined with no BIND(C)
clause do not have the BIND attribute! We should strenuously resist putting
more unnecessary blather into the standard.
Oh, and at max this is "friendly witter". Inserting witter is not necessary
for defect correction. In fact my opinion is that this kind of thing is not
friendly at all but is harmful to comprehension, because it means that in
every other case where we don't say an entity "does not have (laundry-list of
attributes)", the reader will be misled into thinking that maybe it might. No.
No. No. Just don't do it.
And especially there is no case for doing it via interp.
<<<
It is counter-intuitive that they are interoperable and yet do not have
the BIND attribute.
>>>
Not so; plenty of things are interoperable and do not have the BIND attribute.
For an example of another type that is interoperable but does not have the BIND
attribute, see INTEGER(c_int).
<<<
They are defined in an intrinsic module so
the reader cannot look at the definition.
>>>
There is, in fact, no derived-type definition, any more than there is a secret
INTERFACE block for any generic intrinsic. A derived-type definition is a piece
of Fortran syntax in the program, and therefore cannot be exist in anything
intrinsic.
<<<
The present text relies on the distinction between "derived type" in 15.3.3
and "Fortran derived type" in 15.3.4.
>>>
No it does not. I do not know where this bizarre idea comes from.
Nick Maclaren writes:
<<<
I agree with John Reid that it would be better to state explicitly that
they do not have the BIND attribute, but that would not help. Sentences
2 and 3 in 15.3.3 paragraph 2 states that they are interoperable, but
sentence 1 of 15.3.4 paragraph states that a derived type is
interoperable if and only if the Fortran type has the BIND attribute.
>>>
No it does not state that. I am boggled by this assertion! p1 says
"... is interoperable if it has ..."
i.e. It Most Emphatically Does Not Say "ONLY IF".
It is p2 that says that a derived type interoperates with a C struct *if and
only if* it has the BIND attribute. That means that C_PTR and C_FUNPTR
***CANNOT*** have the BIND attribute, because ***they do not interoperate with
any C struct***.
Back to John.
<<<
The term "Fortran derived type" is undefined and is not used anywhere
else in the standard (as far as I can see).
>>>
It is not an undefined term, it is plain English. Grr. I understand why the
authors of that text thought it was useful to drop a few "Fortran" hints in case
the reader got the idea they might have been using a C term, but IMO it was
unnecessary (it has confused John at least!).
<<<
The text of 15.3.3 is similar to 15.2.2 in the Fortran 2003 standard.
In N1622, J3 thought it was unclear and proposed editing 15.2.2 to say
that these types do have the BIND attribute.
>>>
I dispute this account. Though N1622 is ancient history and not relevant
anyway.
The point is that J3 was confused about whether THEY INTENDED for these types
not to have the BIND attribute. There was no confusion in my mind, or likely
in other /DATA or /INTEROP members, as to what the standard actually said,
the question was entirely whether this was a mistake or not!
And if the answer was ever going to be that they had the BIND attribute, of
course an edit was needed as you point out, because in the absence of an edit
they do NOT have the BIND attribute, any more than 42_c_int does.
<<<
2. Was it really intended that a user-defined derived type with
the BIND attribute be permitted to have private components?
>>>
Yes, by analogy with SEQUENCE. In fact BIND is very very like SEQUENCE, the
only real difference being a potential difference in alignment padding.
<<<
It seems to me that this should not be permitted since it
destroys the purpose of declaring components to be private.
>>>
Then we had better prohibit PRIVATE from SEQUENCE types, because it has
Precisely The Same Effect there, and has done since 1991.
We Are Not Going To Do That.
(Aside: we don't even prohibit non-SEQUENCE non-BIND(C) types with PRIVATE
components in the TRANSFER intrinsic, so this idea that PRIVATE is some kind
of impermeable electric fence has never been correct.)
<<<
If it was intended, the rationale should be included in the
answer - this is, after all, an interpretation.
>>>
No rationale is required for this any more than for any other part of the
standard. It has the normal rationale "it got voted in". You don't get us to
write 1000 lines after class if you don't like the answer, that is no more
reasonable than it would be for me to demand to hear from you why everyone
voted for SEQUENCE+PRIVATE back in the day...
J3 has consistently voted against any kind of rationale document. There is no
case to answer here.
Nick writes:
> I also agree with John Reid on question (2), and regard the liberty to
> break the privacy restrictions by using interoperability as a defect in
> the standard.
Well good then, because you cannot "break the privacy restrictions" that way.
The user cannot put BIND(C) on the derived types in the library he is calling.
If it's his own library, *HE CAN DO ANYTHING HE LIKES ANYWAY*.
The Fortran PRIVATE attribute has never ever been this super-restrictive thing
that you and John are imagining. For SEQUENCE types (and thus BIND(C) types)
there are multiple ways of "seeing past the curtain", in these cases all
PRIVATE does is to hide the name when accessing things of the type outside of
a module with a definition. This is not as useful as PRIVATE on an extensible
type, but still has some uses.
Once again, with feeling: BIND(C) is merely the interoperable version of
SEQUENCE, and therefore has basically the same allowances and limitations as
SEQUENCE. There is no defect here.
....................................................................
F03/0065
Corbett comment:
While I would not object to adding a note about relational
equivalence, I do not think relational equivalence should be
allowed to change the results of relational operations. The
Fortran standard claims to promote portability and reliability
of Fortran programs. Allowing a processor to produce the
value false for -2 .LT. 2147483647 does not seem likely to
promote portability or reliability.
The FORTRAN 66 standard allowed a processor to commute and
re-associate the operands of operators when the corresponding
mathematical operators were commutative or associative, but
that was all it explicitly allowed. The concept of integrity
of parentheses made sense in this context. The general notion
of mathematical equivalence was introduced in FORTRAN 77.
It has been a bane of Fortran programmers ever since.
The concept of relational equivalence is specified in
Section 6.6.6 of the FORTRAN 77 standard.
Maclaren NO vote:
This is for the same reasons as David Muxworthy. The wording in 7.1.8.5
dates from Fortran 77, but has never truly corresponded with what
compilers do, no doubt because of the contradictory wording in 7.1.7.5.
Furthermore, if the change to the language is noted, its effects are not
limited to simple examples like this one. For example, many processors
(including even IEC 60559:1989) have multiple representations of the
same value, and it affects which one may be returned. Similarly, the
order of evaluations (e.g. in the MAX intrinsic) can become visible; that
is particularly problematic, because it (mathematically) depends on
solely relational operations.
I disagree with the direction of this interpretation and, in any case,
think that the question of exactly what a value is needs addressing
before an interpretation is appropriate.
Muxworthy No vote:
The interpretation hinges on whether 'values' in F2003 section 7.1.8.5
(and hence F2008 7.1.5.5.2) refers to mathematical values or
computational values.
Provided always that the integrity of parentheses is preserved,
interpretation and evaluation of mathematically equivalent expressions
have been integral to Fortran since its beginning. This concept was
used in compilers in the early 1960s and so was incorporated in F66,
section 6.4. Both F66 (section 6.2 in descriptive English) and F77
(section 6.3.3 explicitly) state that where e1 and e2 are of different
arithmetic types, the value of
e1 relop e2
is the value of
((e1) - (e2)) relop 0
F90 section 7.1.7.5 states, in normative text:
the processor may choose to evaluate the expression
I .GT. J
where I and J are integer variables, as
J - I .LT. 0
and this is repeated as a note in F95 (7.1.7.5) and in F2003
(7.1.8.5).
In F2008 7.1.5.5.2p2 I would contend that (a) as this parsing takes
place at the syntactic level before any computation has started and
(b) for continuity with earlier standards, not to mention 'the spirit
of Fortran', 'value' should be taken to refer to mathematical values,
not computational values.
As a separate matter, the answer to F03/0065 should not state that
what is essentially normative text dating from F90 is 'erroneous'
without flagging this up as a change in language from F2003 to F2008.
I believe the answer should be that
IF( X+3.0 .EQ. 3.0 )...
may be interpreted as
IF( X .EQ. 0.0 )...
Arguably
IF( (X+3.0) .EQ. 3.0 )...
can not be so interpreted since the latter implies that some
computation must be done before the comparison.
Therefore to have no edit is wrong. There should be clarification of
what 'values' means in this context and, if 7.1.5.5.2 is now deemed to
refer to computational values, this change to the long-established
interpretation of mathematical equivalence should be recorded as a
change to the language.
....................................................................
F03/0065: Replies from the editor
David Muxworthy writes:
<<<
The interpretation hinges on whether 'values' in F2003 section 7.1.8.5
(and hence F2008 7.1.5.5.2) refers to mathematical values or
computational values.
>>>
The clear meaning of "all possible values" is "all values that are possible".
Otherwise we'd have simply written "mathematically equivalent" if that is what
we meant.
I find it somewhat boggling to hear 3 users say that they are happy to get the
wrong answer for a relational operator, when no vendors are complaining that
their hardware cannot do it fast enough. I used a mini-computer in the 70s
that did not have a comparison instruction, but then it did not have multiply,
divide, or even subtraction either! But Fortran still required all those to
work. These days, even my washing machine has hardware to do a correct
comparison!
<<<
Both F66 (section 6.2 in descriptive English) and F77 (section 6.3.3
explicitly) state that where e1 and e2 are of different arithmetic types,
the value of
e1 relop e2
is the value of
((e1) - (e2)) relop 0
>>>
Sure, but F66 and F77 say *lots* of things that are no longer true. We changed
this in F90, that is already over 20 years ago.
<<<
F90 section 7.1.7.5 states, in normative text:
the processor may choose to evaluate the expression
I .GT. J
where I and J are integer variables, as
J - I .LT. 0
and this is repeated as a note in F95 (7.1.7.5) and in F2003 (7.1.8.5).
>>>
Right, and we removed this erroneous note in F2008 (paper 07-211).
<<<
this change to the long-established interpretation of mathematical
equivalence should be recorded as a change to the language.
>>>
It is not a "change to the language" to insist that something gives the right
answer: it was not forbidden to give the right answer before!. Furthermore,
the change occurred in the big rewrite for F90; yes, that left an
inconsistency which was finally removed in F2008, but by then it was removing
bad advice, nothing more.
It is ironic that at least one of the people who would be happy for relational
operations to give the wrong answer was also insistent in F2003 that ATAN2 be
bit-perfect re negative vs positive zero! Obviously ATAN2 is a function that
is *so* much more important to get right than comparison...
I agree with Robert Corbett: there is no gain in portability or usability by
allowing comparisons to return the wrong answer. We should stick with the
text as written.
....................................................................
F03/0084
Bader NO vote:
The answers given to both (1) and (2) in the interp appear to me
to be counterintuitive; the programmer would expect that the
calculation of Z1 and Z2 respectively obey the imposed rounding
mode. In particular, I suspect there are situations where it is
more obvious to the compiler than to the programmer that expressions
are evaluated at compile time, and that different processors may
have differing capabilities in identifying such expressions. The
resolution of such situations is one target that the IEEE facilities
were designed for. I therefore am in favor of the stance that, if
supported, the setting of the rounding mode should take precedence
over processor-dependent compile-time evaluations.
Corbett NO vote:
I disagree with the interpretation given. I believe that the
assignments should require conversions to be done and that the
conversions should be done in accord with the rounding mode
currently in effect. Therefore, the results should not be zero.
Long NO vote:
I was confused by John's comment that the rounding mode on
entry to the subroutine affected the value of Z1 since the computation
of Z1 follows a call that resets the rounding mode. I think the real
question here is what the standard means by "mathematical". I had
always thought in terms of things like algebra. John's answer seems
to imply that computational numerics (as specified by IEEE) are part
of the concept of "mathematical". In other contexts, I think that
John's interpretation could be harmful. On the other hand, the
current answer does seem to make the usefulness of the
IEEE_SET_ROUNDING_MODE routine more limited that would be
expected. Also, does the concept of mathematically equivalent apply to
the aggregation of multiple statements, or does it apply to just one
expression? A processor that used the "mathematically equivalent"
argument to get 0 would need to forward sub the expressions for Z1 and
Z2 into the print statement to get X*Y - X*Y. I don't think we
intended to allow forward substitution of expressions across one of
the IEEE mode setting routines.
Maclaren comment:
This relates to F03/0065, but is the other way round. Unlike that one,
I consider this consistent with the majority of the semantic wording in
the C standard.
Muxworthy No vote:
I agree with John's vote.
Reid NO vote:
The IEEE rounding mode on entry to the procedure may vary from
call to call. The value of Z1 depends on this rounding mode.
Therefore, the processor should not always print zero for Z1-Z2.
Whether or not Z1 and Z2 have the PARAMETER attribute makes no
difference. Yes, the processor is allowed to evaluate an
expression in any mathematically equivalent way, but here the
mathematics dictates that a particular form of rounding, defined
in the IEEE standard, be applied.
Snyder NO vote:
The answer makes rounding mode changes pointless.
The work-around usually advanced to cause rounding mode changes to
have effect (but not advanced in the answer to the interpretation)
is to store intermediate results that are computed with different
rounding modes in VOLATILE variables if they are ultimately to be
combined in a single expression.
Subclause 5.3.19 states, in part, however, that "The VOLATILE
attribute specifies that an object may be referenced, defined, or
become undefined, by means not specified by the program." Setting
the rounding mode is done by means that ARE specified by the
program, so the advice is not germane. One who reads subclauses
5.3.19, 14.4, 14.11.6, and 14.11.21, and the answer to this
interpretation, might not realize that the use of VOLATILE variables
is required, under the present interpretation, for subclauses 14.4,
14.11.6, and 14.11.21 to be meaningful.
A better answer would have been to amend 7.1.5.2.4 to require that
all entities within the expression are evaluated with the same
rounding mode, or to specify that quantities evaluated with
different rounding modes cannot be considered to be mathematically
equivalent, even if evaluated by textually identical expressions.
This might require processors either to abandon certain
optimizations, or to perform more detailed dataflow analysis that
propagates rounding mode to determine when those optimizations are
permitted.
If the position implied by the answer to this interpretation is to
be maintained, the absence of edits is entirely inadequate. The
definition of VOLATILE must be changed to encompass actions that ARE
specified by the program, and to encompass advice concerning
rounding mode changes. Advice to store intermediate results that
are computed with different rounding modes into VOLATILE variables,
if they are to be combined in a single expression, must be included
in subclauses 14.4 and 14.11.21.
During the requirements phase for the 2008 standard, there was a
request (in 04-219) for a "strict mode" similar to that described in
section G.2 of the Ada standard, in which rounding mode settings
would actually have an effect without needing to resort to VOLATILE
variables. If a "strict mode" had been provided, it might have made
sense to allow a processor to ignore rounding mode changes outside
strict regions. A request for a "strict mode" will be presented
during the requirements-gathering phase for the next revision of the
standard, for this as well as other reasons.
....................................................................
F03/0084: Replies from the editor
John Reid writes:
<<<
The IEEE rounding mode on entry to the procedure may vary from
call to call. The value of Z1 depends on this rounding mode.
Therefore, the processor should not always print zero for Z1-Z2.
Whether or not Z1 and Z2 have the PARAMETER attribute makes no
difference. Yes, the processor is allowed to evaluate an
expression in any mathematically equivalent way, but here the
mathematics dictates that a particular form of rounding, defined
in the IEEE standard, be applied.
>>>
No it does not. IEEE peculiarities play no part in the mathematical Reals.
IEEE is merely one form of computer arithmetic. (It would make very bad
mathematics, since IEEE numbers are not even a subset of the 2-point
compactification of the Reals, thus nearly all mathematical identities and
theorems about the Reals would get destroyed.) Computer arithmetic is
*computational* not *mathematical*. ALL computer arithmetics frequently give
different computational answers for mathematically-equivalent expressions.
And I cannot believe you are again trotting out this nonsense saying constant
expressions should not be treated as constant. If I have
"REAL(KIND=INT(a+b)) :: x(INT(a+b)) = a+b; y=a+b",
with a and b being floating-point named constants, I am not allowed to
evaluate a+b at compile time? Surely you jest. Or I can in the KIND= but
not in the array bound? Unless the array is in COMMON or has the SAVE
attribute? Surely you jest even more. Or I can everywhere except in the
"y ="? You cannot be serious.
Furthermore, the rationale you are using is applicable to all routines
regardless of whether they call IEEE_SET_ROUNDING and would thereby destroy
many basic optimisations. You.Really.Can.Not.Be.Serious.
....................................................................
F03/0103
Chen NO vote:
The reason for the 'NO' vote on F03/0103 is because:
Passing a polymorphic optional argument that is not present to a
non-polymorphic optional dummy should be disallowed as it requires
de-referencing the descriptor. There are rules that disallow passing a
pointer dummy or allocatable dummy that is not present as actual argument
to a nonpointer nonallocatable optional dummy (12.5.2.12p3 (7)/(8)).
There should be a similar rule for prohibit passing a polymorphic optional
argument that is not present to a non-polymorphic optional dummy. I am
aware that adding a runtime checking can solve the problem, but it will
impact the performance.
....................................................................
F03/0120
Snyder comment:
There are typos in the discussion following question (5). In the
fourth line of the second paragraph delete "are" before "can". In
the sixth line of the second paragraph after the example after
question (5), replace "It" before "2" with "Is". In the third line
of the third paragraph delete "of" before "different".
....................................................................
F03/0121
Bader NO vote:
The answer as a whole seems misleading; given the specification
of the REAL intrinsic and existing rules for type conversions (or
their absence) in expressions, the answer should simply be "yes".
The reference to mathematically equivalent expressions is mostly
irrelevant (since by parenthesization the programmer's purpose
should very likely be achievable), and that to VOLATILE variables
is simply unnecessary.
Corbett NO vote:
I previously voted for the answer given. Since then, I
have been convinced I was mistaken. I no longer think
that REAL(X), where X has type REAL but has a different
kind type parameter value from that of type default real,
should be considered mathematically equivalent to X. I
now agree with Mr. Braams that the intrinsic function REAL
should do a real conversion.
I agree with Van that nothing in the standard or in the
existing interpretations requires VOLATILE to force a
conversion. Interpretation F90/000001 is the only
interpretation I have found that addresses the issue,
and it, of course, could not require the use of VOLATILE.
I agree with John that VOLATILE should not be required to
force a conversion.
Long NO vote:
Similar to F03/0084, this hinges on the meaning of "mathematical".
I'm not convinced that a processor is allowed to treat
X and REAL(X,wp) as mathematically equivalent. The REAL function
(may) perform an operation that is outside the scope of normal
algebra.
Maclaren comment:
The recommendation to use VOLATILE is wrong. There is a common myth in
among C and C++ programmers and even in informative text in the
standards that volatile implies this semantic, but it is not justified
by their normative text, nor do all compilers support it. Fortran
should not follow suit - in particular, Fortran 2008 5.3.19 makes no
such guarantee.
In particular, because 5.3.19 provides licence to the processor and not
to the programmer, a compiler is at liberty to optimise all references
to VOLATILE variables if it does not provide any method of accessing it
other than those specified by the program. Regrettably, the correct
response is:
There is no feature in Fortran to provide this facility, though
assignment to a VOLATILE variable will often work. On some
processors, making that a BIND(C) variable in a module will be
needed but, on a few, this recipe will not work at all.
This should be addressed properly in a future revision.
Muxworthy comment:
Like Van, I find the Answer unsatisfactory although the outcome (no
edit) is correct. The answer is Yes. This is stated clearly in
13.7.138. What a processor might or might not do behind the scenes is
irrelevant. If it does not obey 13.7.138 it is non-standard-
conforming. (We are talking about a high-level language, not C).
Reid NO vote:
I think it is unacceptable to recommend the use of the VOLATILE
attribute for a variable that is referenced, defined, or becomes
undefined only within the Fortran program. The desired effect
may be obtained by assigning the intermediate result to a
variable without the VOLATILE attribute because this rules out
the exceptions explained in the final sentence of the first
paragraph of the answer ("Furthermore, ...").
Snyder NO vote:
The answer refers to subclause 7.1.5.2.4 without identifying that
subclause: "the processor may evaluate any mathematically
equivalent expression, provided that the integrity of parentheses is
not violated," and uses that as justification for the answer.
Subclause 7.1.5.2.4 is entirely irrelevant to the question.
Subclause 4.1.2 specifies that "For each type there is a set of
valid values." Subclause 4.2 specifies that "the set of values...
depend[s] on the values of the parameters."
Subclause 13.7.2, as amended by the answer to interp F08/0008,
says, in part, "A program shall not invoke an intrinsic procedure
under circumstances where a value ... returned as a function result
is not representable by objects of the specified type and type
parameters."
Allowing the REAL intrinsic function to return a result that is
claimed to have a specified kind, and a value that is not a member
of the set of valid values for that kind, violates the requirements
of subclauses 4.1.2, 4.2, and 13.7.1 as amended by interpretation
F08/0008. An interpretation should not introduce an inconsistency
that will later need to be resolved by yet another interpretation.
Even if F08/0008 were to fail, the result of the answer to this
interpretation would be to introduce a conflict to 13.7.1 status quo
ante, which reads, in part, "A program is prohibited from invoking
an intrinsic procedure under circumstances where a value to be
returned in a subroutine argument or function result is outside the
range of values representable by objects of the specified type and
type parameters," and continues with caveats not germane to the
present interpretation.
The only reason ever to invoke the REAL intrinsic function with a
real argument and a KIND argument is to produce a result with the
specified kind, and a value that is a member of the set of valid
values for that kind. This is exceedingly rare, except perhaps as
an actual argument (where the processor must necessarily produce a
value that is a member of the set of valid values, and additionally
is represented by the specified type and kind), and therefore
requiring processors to produce a value for the result of REAL that
is a member of the set of valid values for the kind of the result
would have no measurable effect on performance in any program other
than an arcane SPEC benchmark.
The answer should be "Although a processor is allowed to replace an
expression with a mathematically equivalent expression, subclauses
4.1.2, 4.2, and 13.7.1 (or 13.7.1 as amended by interpretation
F08/0008) require the value of the result of every intrinsic
function to be a member of the set of valid values for the type and
kind of the function result." No normative edits would be required,
although it would be helpful to add a recommendation in a note (or a
requirement) to 13.7.138p5 Case (i) that the result have a value
that is not different from the argument by more than one unit in its
least significant place (unless the argument is NaN), and that it be
rounded according to IEC 60559:1989 and the rounding mode currently
in effect if the IEEE_ARITHMETIC module is accessible (unless the
argument is NaN).
Advice in the presently proposed answer is offered to use the
VOLATILE attribute. Subclause 5.3.19 states, in part, however,
that "The VOLATILE attribute specifies that an object may be
referenced, defined, or become undefined, by means not specified by
the program." Invoking the REAL intrinsic function is a means that
IS specified by the program, so the advice is not germane.
One who reads subclauses 4.1.2, 4.2, 5.3.19, 7.1.5.2.4 and 13.7.1
would have no clue that the way to make REAL operate as essentially
all users expect it to operate is to store its result into a
variable that has the VOLATILE attribute! If one must have the
presently proposed answer, having no edits is entirely inadequate.
Subclause 5.3.19 must be amended to include effects that ARE
specified by the program. Subclauses 5.3.19 and 13.7.138 must be
amended to include advice to use the VOLATILE attribute to make REAL
function as essentially all users expect it to. Further, there must
be an explicit exemption for REAL in subclause 13.7.1, and maybe in
4.1.2 and 4.2 as well.
A perverse reading of 13.7.1, adroitly sidestepping subclauses 4.1.2
and 4.2, might be that a function is allowed to return a value that
is not a member of the set of valid values for the type and kind of
the result, but that a program is not allowed to invoke the function
in such a way as to produce that result. This would make it illegal
instead of pointless to invoke the REAL intrinsic function with the
hope to produce a value that is a member of the set of valid values
for the kind of the result. That is, for example, that REAL is
permitted to act consistently with the present answer to this
interpretation, but a program is not permitted to invoke
REAL(3.14159265358979323846264338d0,kind(1.0e0)) if the processor
uses 32-bit IEEE arithmetic for default real, because the result
would not be a member of the set of valid values. If so, in order
to detect programs that are not standard conforming, a helpful
processor should announce an error in this circumstance, which
requires producing a value that is a member of the set of valid
values, and comparing it to the proposed result value instead of
using it as the result value. One might argue that 13.7.1 was
aimed, for example, at SQRT(-1.0), for which the mathematical
function approximated by the intrinsic function has no values that
are representable by the type and kind of the result. But it
doesn't say so, and that argument does not reasonably apply to
REAL. Since 13.7.138p5 Case (i) explicitly says that REAL produces
an approximation to its argument, it is more reasonable for
REAL(3.14159265358979323846264338d0,kind(1.0e0)) to produce an
approximation that is a member of the set of valid values for the
kind of the result, than for its invocation to be prohibited, or for
it to produce a result that is not a member of the set of valid
values for the kind of the result.
If a processor absolutely must reduce REAL with a real argument to
the identity operation under certain circumstances, a command-line
argument to cause this behavior could be provided, with a caveat
that using that setting admits behavior that is not consistent with
the standard.
....................................................................
F03/0121: Replies from the editor
<<<
I think it is unacceptable to recommend the use of the VOLATILE
attribute for a variable that is referenced, defined, or becomes
undefined only within the Fortran program. The desired effect
may be obtained by assigning the intermediate result to a
variable without the VOLATILE attribute because this rules out
the exceptions explained in the final sentence of the first
paragraph of the answer ("Furthermore, ...").
>>>
Well no. Inter-statement optimisation is alive and well (re, in spite of
F90/000001: some vendors have to compete on SPEC benchmarks and the like!),
and the people moaning about the REAL() intrinsic not doing what they want
frequently also want the optimisation cranked up to that level. In that case,
VOLATILE is something that does, in fact, work.
One might plausibly argue that we are being more helpful here than we need to.
Nick opined:
<<<
... is a common myth in among C and C++ and even in informative text in the
standards that volatile implies this semantic
>>>
If informative text in the standard implies this semantic, that is a clear
indication of the intent of the C committee.
<<<
but it is not justified by their normative text,
>>>
That is your opinion. You might or might not be right. My understanding of
the normative text is otherwise i.e. the same as the informative implication.
I might or might not be right. Under the circumstances, since this is the
Fortran committee not the C committee, we should take the informative text
as being correct rather than what some of the barracks-room lawyers say.
<<<
nor do all compilers support it
>>>
Many compilers have many bugs in many areas, and volatile is no exception to
this. Indeed, papers have been written on such very topics. However, this
case is very simple (no multi-threading required!) and in my experience it
does work reliably.
....................................................................
F08/0004
Corbett NO vote:
I agree with the answer given, but I think the edit as
written is likely to confuse readers. Given just the
edit without the context of the interpretation, I would
be hard put to figure out what it meant. I suggest the
following alternative edit:
If ASSOCIATED is invoked with two actual arguments
and the argument corresponding to TARGET is a pointer,
TARGET shall be considered to be a present pointer.
....................................................................
F08/0008
Corbett comment:
I agree with the answer given, but I shall note that the
conditions given could be tightened. Specifically, the
sentence
If an IEEE NaN is assigned or returned, the actual
arguments were finite numbers, the intrinsic module
IEEE_ARITHMETIC is accessible, and the exception
IEEE_INVALID is supported, the flag IEEE_INVALID
shall signal.
could say
If an IEEE NaN is assigned or returned, the actual
arguments were (possibly infinite) numbers, the
intrinsic module IEEE_ARITHMETIC is accessible, and
the exception IEEE_INVALID is supported, the flag
IEEE_INVALID shall signal.
The edits as written are correct, just not as tight as
they could be.
....................................................................
F08/0032
Bader comment:
The additional constraint C1276b at first surprised me, since it
seemed at first sight not to be connected with the problem dealt
with in this interp. Rereading F08/0033 - which is incorporated
in corrigendum 1 - it seems this must be included for similar
reasons as the INTENT(OUT) case dealt with there. Still, this
new restriction as well as the one introduced in F08/0033 seems
a rather large hammer, because it also impacts the case where
no finalizers at all are defined (and of course there now is the
incompatibility with F2003). Therefore I wonder whether it would
not be better to fix the finalizer part of the scheme by
requiring that if a pure finalizer is defined for some type, any
extension type that has a finalizer must also use a pure procedure
for it. This would be a much smaller-impact change if feasible,
but of course would imply re-working of F08/0033 as well.
More information about the J3
mailing list