<html><body><p><tt>JT> There was no intention for widening to apply to unary operators.</tt><br><br>On IA32 (x86), non-SIMD floating-point operations normally use 80 bit double extended registers. For that architecture, for "x = -y;" the values of y and of -y in registers would be in 80 bit double extended format prior to the store into x. If instead of loading then negating a negate from memory into a register would also result in the value of -y being in DE format. Wouldn't that mean that on IA32 (x86) widening could apply to unary operators?<br><br>- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development<br><br><br><img width="16" height="16" src="cid:1__=8FBBF54FDFE8D65F8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Jim Thomas ---2016-06-21 04:54:24 PM---The CFP group will discuss this and three subsequent comments "><font color="#424282">Jim Thomas ---2016-06-21 04:54:24 PM---The CFP group will discuss this and three subsequent comments from Joseph at its June teleconference</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Jim Thomas <jaswthomas@sbcglobal.net></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Joseph Myers <joseph@codesourcery.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">CFP <cfp-interest@ucbtest.org>, SC22 WG14 <sc22wg14@open-std.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2016-06-21 04:54 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [Cfp-interest] (SC22WG14.14278) FLT_EVAL_METHOD, exceptions and lvalue-to-rvalue conversion</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">cfp-interest-bounces@oakapple.net</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>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.<br><br>The wording in the first sentence of 5.2.4.2.2 #9, which currently is<br><br>"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.”,<br><br>is problematic. There was no intention for widening to apply to unary operators.<br><br>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<br><br>“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.)”<br><br>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.<br><br>I think we should address the wording in 5.2.4.2.2 #9 before we try to resolve Joseph’s issue.<br><br>Jim Thomas<br><br>> On Jun 9, 2016, at 2:32 PM, Joseph Myers <joseph@codesourcery.com> wrote:<br>> <br>> Suppose that with an implementation of C11 + TS 18661-1, that defines <br>> FLT_EVAL_METHOD to 2, you have:<br>> <br>> static volatile double x = SNAN;<br>> (void) x;<br>> <br>> Suppose also that the implementation defines the "(void) x;" statement to <br>> constitute an access to volatile-qualified x.<br>> <br>> May the implementation define that access to convert x from the format of <br>> double to the format of long double, with greater range and precision, <br>> that format being used to represent double operands in accordance with the <br>> setting of FLT_EVAL_METHOD, and thereby to raise the "invalid" exception?<br>> <br>> That is, may a convertFormat operation be applied as part of <br>> lvalue-to-rvalue conversion where FLT_EVAL_METHOD implies that a wider <br>> evaluation format is in use?<br>> <br>> Even without signaling NaNs, the issue can apply to the case of exact <br>> underflow, which can be detected using pragmas from TS 18661-5, if the <br>> wider format has extra precision but not extra range and so exact <br>> underflow occurs on converting a subnormal value to the wider format.<br>> <br>> -- <br>> Joseph S. Myers<br>> joseph@codesourcery.com<br><br><br>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br></tt><tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a></tt><tt><br></tt><br><br><BR>
</body></html>