To: J3 Members J3/16-118
From: Van Snyder
Subject: Interp F03/0121: Precise FP semantics of the REAL intrinsic
Date: 2016 January 25
Interp F03/0121 "Precise FP semantics of the REAL intrinsic" failed
with more NO votes than almost any other interp.
The answer was founded upon the permission enunciated in subclause
7.1.5.2.4, paragraph 2, of 10-007r1, viz.
"Once the interpretation of a numeric intrinsic operation is
established, the processor may evaluate any mathematically
equivalent expression, provided that the integrity of parentheses
is not violated."
Using this as an excuse to say that the REAL intrinsic function does
not need to produce a result that is a valid member of the set of
values for the result type and kind overlooks that it explicitly
applies only to numeric intrinsic operations, i.e., it does not apply
to intrinsic function results.
If one considers the first sentence of 4.1.2, viz.
"For each type there is a set of valid values"
and the second sentence of subclause 4.2, which says, in part
"... the set of values ... depend[s] on the values of the
parameters"
and the fourth sentence of 13.7.1 paragraph 2 (as amended by
Corrigendum 2), viz.
"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."
one observes that an intrinsic function is either prohibited from
returning a value that is not a member of the set of valid values for
the type and kind of the result, or the program is prohibited from
invoking it if it would do so. It is unhelpful that the description
of an intrinsic function specifies the type and kind of its result,
and therefore the set of valid values, but then the function is
allowed to return a value that is not a member of that set, and
therefore the function cannot reliably be invoked.
If a provision of the standard can be interpreted such as to
contradict other provisions of the standard, or such as to conform to
other provisions of the standard, the interpretation that conforms
must necessarily be the correct one.
Therefore, notwithstanding the apparent permission in 7.1.5.2.4p2,
which in fact does not apply to intrinsic functions, applying this
permission so as to violate provisions in other parts of the standard,
in particular subclauses 4.1.2, 4.2, 7.1.5.2.4p1, and 13.7.1, is
clearly not intended.
----------------------------------------------------------------------
NUMBER: F03/0121
TITLE: Precise FP semantics of the REAL intrinsic
KEYWORDS: REAL intrinsic
DEFECT TYPE: Clarification
STATUS: J3 consideration in progress
QUESTION:
Must the intrinsic function REAL with KIND argument wp return a value
that is a REAL (KIND=wp) floating point number?
RATIONALE FOR THE QUESTION:
Computer hardware may use a wider floating-point format for registers
than for memory; e.g., 80 bits for registers and 64 bits for memory
for the case of standard double precision floating point numbers. Some
algorithms require a high level of control over floating point
semantics. If the intrinsic function REAL with KIND parameter wp is
guaranteed to return a REAL (KIND=wp) result then a programmer can use
this to force intermediate results into main memory format, never mind
that the optimizing compiler may have placed the intermediate in a
register.
I am interested in a J3 interpretation of this matter, especially a
loud and clear affirmative interpretation, because it appears that
some present Fortran compilers optimize away my explicit use of the
REAL intrinsic with a KIND=wp argument. The context is code for
compensated summation (Kahan summation). I appreciate that
parentheses are inviolable courtesy of the Fortran standard, but in
order to have code that cannot be broken by an optimizing compiler I
seem to need also a language mechanism to force intermediate results
into main memory format. The VOLATILE attribute is a large hammer,
and the standard does not actually say that assigning a value to a
variable with that attribute forces the result to main memory format.
Bas Braams
Chemistry Department and
Emerson Center for Scientific Computation
Emory University
Atlanta, GA
ANALYSIS:
The fourth sentence of the second paragraph of subclause 13.7.1, as
amended by Corrigendum 2, states:
"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."
The first sentence of subclause 4.1.2 states:
"For each type there is a set of valid values."
The second sentence of subclause 4.2 states, in part:
"... the set of values ... depend[s] on the values of the
parameters."
Therefore, the result of the REAL intrinsic function is required to be
a value that is a member of the set of valid values for the kind of
the result.
ANSWER:
An argument has been made that subclause 7.1.5.2.4, paragraph 2, of
10-007r1, viz.
"Once the interpretation of a numeric intrinsic operation is
established, the processor may evaluate any mathematically
equivalent expression, provided that the integrity of parentheses
is not violated."
allows the REAL intrinsic function to return a mathematically
equivalent result. This subclause explicitly applies only to numeric
intrinsic operations, not intrinsic function results.
An argument has been made that an interpretation of the clear language
of subclause 13.7.1 paragraph 2, together with subclauses 4.1.2 and
4.2, that requires the REAL intrinsic function to return a value that
is a member of the set of valid values of the kind of its result,
would cause processors to produce slower programs. Users who need
precise floating-point semantics for the REAL intrinsic function might
object when they realize that those same semantics apply to other
numeric intrinsic functions, such as SQRT and COS, where extra
precision is helpful, not actively harmful.
This problem could be addressed by a revision of the standard; the
interpretation process is not the way to do it. Meanwhile, processors
could offer an option to provide non-conformant behavior.
ALTERNATIVE ANSWER (i.e., the interp process is OK for new featues):
That the second paragraph of subclause 13.7.1 either requires an
intrinsic function to return a value that is a member of the set of
valid values for the type and kind of its result, or the function
cannot be invoked if it returns a value outside that range, is too
strong if the intrinsic function does not have an optional argument
that specifies the kind of the result, or if it has such an argument
but a corresponding actual argument does not appear where the
function is invoked.
Edits are supplied to correct this mistake.
EDITS to 10-007r1:
None.
ALTERNATIVE EDITS to 10-007r1, as amended by Corrigendum 2:
Replace the fourth sentence of the second paragraph of subclause
13.7.1:
"If a reference to a numeric intrinsic function includes an argument
that specifies the kind of its result, a program shall not execute
that reference under circumstances where the value to be assigned as
its result is not representable by objects of the specified type and
type parameters. A program shall not invoke an intrinsic subroutine
under circumstances where a value to be assigned to any of its
arguments is not representable by objects of the type and type
parameters specified for that argument. Otherwise, if a reference
to a numeric intrinsic function has no argument that specifies the
kind of its result, the result may be of a different kind from
default kind, provided that values of the kind of the result have
the same radix, no fewer decimal digits of precision, and an
exponent range that is not smaller than for default kind, if the
result is of real or complex type, or no fewer decimal digits than
default kind if the result is of integer type."
Insert a note after this paragraph:
"NOTE 13.7a
The provision in 7.1.5.2.4 that allows a processor to evaluate a
mathematically equivalent expression applies only to numeric
intrinsic operations, not to intrinsic functions."
SUBMITTED BY: Bas Braams, Emory University, Atlanta, GA
HISTORY: 08-208r1 m185 F03/0121 submitted
10-240 m193 Draft answer for F2008 - Passed by J3 meeting
11-129 m194 Passed by J3 letter ballot #22 10-254
N1878 m186 Failed WG5 ballot 1 N1876
11-260 m196 Revised answer
11-260r1 m196 Passed by J3 meeting
12-165r2 m198 Passed by J3 letter ballot #25 12-147
12-193 m199 Failed WG5 ballot #3 N1932/N1933/N1939
----------------------------------------------------------------------