To: J3 Members J3/16-117r1
From: Van Snyder & Stan Whitlock
Subject: New feature: Precise FP semantics for REAL intrinsic
Reference: 04-218, 16-007, interp F03/0121
Date: 2016 February 10
0. Resolution
=============
This paper describes a new feature for F2015 which is an incompatibility
with F2008. The new feature would exempt intrinsic functions from
the F2008 allowance:
10-007r1 [141:20-21] 7.1.5.2.4p2
"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."
New features for F2015 are out of order at this meeting. Therefore there
will be no further action taken on the issues in 16-117. The remainder
of the paper is for reference only.
1. Introduction
===============
Disagreement concerning the floating-point semantics of the REAL
intrinsic function existed long before interp F03/0121.
Some users need the precise control required by 13.8.1p2, viz.
"A program shall not invoke an intrinsic procedure under circumstances
where a value to be assigned to a subroutine argument or returned as a
function result is not representable by objects of the specified type
and type parameters."
Vendors argue that (like Volkswagen), they cheat to provide better
performance (and maybe better mileage), by incorrectly invoking
7.1.5.2.4p2, 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."
which applies only to numeric intrinsic operations, and thereby ignoring
that a too-broad interpretation of it contradicts 13.8.1p2.
The comments accompanying the NO votes on the most recent ballot
concerning F03/0121 objected that current practice, no matter how useful
in some circumstances, violates 13.8.1p2, and that complying with
13.8.1p2 is valuable to at least some users.
A compromise is proposed here that ought to satisfy both camps, and
would moot F03/0121. It is not provided as a proposed answer to
F03/0121 because it is a new feature that ought not to be introduced via
the interpretation process.
An alternative to this compromise is to answer F03/0121 that all
intrinsic functions, and in particular the REAL intrinsic function, are
required to return result values that are representable by the type and
kind of their results, as currently required by 13.1.1p2, because
7.1.5.2.4p2 applies only to numeric intrinsic operations, not intrinsic
functions. Vendors (and users) might complain that this brush is too
broad, eliminating useful possibilities for other intrinsic functions
such as SQRT and COS. Vendors can provide a command-line option that
allows behavior that is not conformant to this provision.
2. Edits
========
[336:7-8 13.8.1p2] Replace the final sentence of 13.8.1p2 with the
following:
"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."
Then insert a note after 13.8.1p2:
"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."
This allows processors to provide more precision in the result of
REAL() or SQRT(), but not in the result of
REAL(,kind(0.0e0)). It provides necessary tools to users who need
precise floating-point semantics of the REAL intrinsic function, while
preserving opportunities for optimization where the kind type parameter
is not specified.