[Cfp-interest] (SC22WG14.14278) FLT_EVAL_METHOD, exceptions and lvalue-to-rvalue conversion

[Jim Thomas]

The CFP group will discuss this and three subsequent comments from Joseph at its June teleconference on Tuesday (June 28). My initial responses are here and in email to follow responding to the other comments.

The wording in the first sentence of 5.2.4.2.2 #9, which currently is

"Except for assignment and cast (which remove all extra range and precision), the values yielded by operators with floating operands and values subject to the usual arithmetic conversions and of floating constants are evaluated to a format whose range and precision may be greater than required by the type.”,

is problematic. There was no intention for widening to apply to unary operators.

This issue came up at the 2013 WG14 meeting in Chicago. There was some informal follow-up but I don’t believe it was resolved. My last recommendation for a replacement for the sentence above was

“The floating-point values yielded by operators subject to the usual arithmetic conversions, and values of floating constants, may be evaluated to a format with greater range and precision than required by the type. (Extra range and precision in operands of operations subject to the usual arithmetic conversions is not removed.)”

There’s no need to mention assignment and cast, since they are not subject to the usual arithmetic conversions. I parenthesized the second sentence, because I believe what it says in inherent in the existing evaluation model. If this is not true, then the parentheses should be removed.

I think we should address the wording in 5.2.4.2.2 #9 before we try to resolve Joseph’s issue.

Jim Thomas

> On Jun 9, 2016, at 2:32 PM, Joseph Myers <joseph at codesourcery.com> wrote:
> 
> Suppose that with an implementation of C11 + TS 18661-1, that defines 
> FLT_EVAL_METHOD to 2, you have:
> 
> static volatile double x = SNAN;
> (void) x;
> 
> Suppose also that the implementation defines the "(void) x;" statement to 
> constitute an access to volatile-qualified x.
> 
> May the implementation define that access to convert x from the format of 
> double to the format of long double, with greater range and precision, 
> that format being used to represent double operands in accordance with the 
> setting of FLT_EVAL_METHOD, and thereby to raise the "invalid" exception?
> 
> That is, may a convertFormat operation be applied as part of 
> lvalue-to-rvalue conversion where FLT_EVAL_METHOD implies that a wider 
> evaluation format is in use?
> 
> Even without signaling NaNs, the issue can apply to the case of exact 
> underflow, which can be detected using pragmas from TS 18661-5, if the 
> wider format has extra precision but not extra range and so exact 
> underflow occurs on converting a subnormal value to the wider format.
> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com