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