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

[Ian McIntosh]

JT> There was no intention for widening to apply to unary operators.

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?

- Ian McIntosh          IBM Canada Lab         Compiler Back End Support
and Development




From:	Jim Thomas <jaswthomas at sbcglobal.net>
To:	Joseph Myers <joseph at codesourcery.com>
Cc:	CFP <cfp-interest at ucbtest.org>, SC22 WG14
            <sc22wg14 at open-std.org>
Date:	2016-06-21 04:54 PM
Subject:	Re: [Cfp-interest] (SC22WG14.14278) FLT_EVAL_METHOD,
            exceptions and lvalue-to-rvalue conversion
Sent by:	cfp-interest-bounces at oakapple.net



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


_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20160624/4c912e2f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20160624/4c912e2f/attachment.gif