To:         J3 Members                                       J3/16-118r1
From:       Van Snyder & Stan Whitlock
Subject:    Interp F03/0121: Precise FP semantics of the REAL intrinsic
Date: 2016 February 10

----------------------------------------------------------------------

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."

However common optimizations have allowed the REAL intrinsic to be
ignored in an expression when the result is mathematically equivalent
to including the evaluation of the REAL intrinsic.  Requiring the
evaluation of the REAL intrinsic in all circumstances would be adding a
new feature, incompatible with existing F2008 interpretations, and would
be limiting optimizations on which Fortran customers rely.

ANSWER:

10-007r1 [141:20-21] 7.1.5.2.4p2, says:

   "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."

The interpretation of this paragraph has always meant that the REAL
intrinsic may return a mathematically equivalent result.  The interp
process must not be used to add a new feature, incompatible with existing
practice.

EDITS to 10-007r1:

None.

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
         16-118    m209  F03/0121 resubmitted as a new feature
         16-118r1  m209  New feature not allowed; clarification

----------------------------------------------------------------------