To: J3 Members J3/16-117 From: Van Snyder Subject: Re: Interp F03/0121: Precise FP semantics for REAL intrinsic Reference: 04-218, 16-007 Date: 2016 January 25 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.