This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Fix PR28684
- From: Richard Guenther <rguenther at suse dot de>
- To: Revital1 Eres <ERES at il dot ibm dot com>
- Cc: Clint Whaley <whaley at cs dot utsa dot edu>, roger at eyesopen dot com, Ayal Zaks <ZAKS at il dot ibm dot com>, Dorit Nuzman <DORIT at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 16 Nov 2006 14:47:16 +0100 (CET)
- Subject: Re: [RFC] Fix PR28684
- References: <OF89AA15CE.57B6C9F8-ONC2257228.003F6254-C2257228.004974DB@il.ibm.com>
On Thu, 16 Nov 2006, Revital1 Eres wrote:
>
> > It doesn't seem obvious to me why reordering the operations messes up the
> > sign on zero (AFAIK that's not order based?), can you clarify? As to if
> > it's OK, like the guys who care about order, I think the times you need
> > positive/negative zero differentiation are very rare, so it won't keep
> people
> > from using the flag. However, if it can occur, it should probably be
> mentioned
> > in the flag definition, as I don't think it is obvious (at least to me)
> why
> > it would happen from the present description. Probably it would be more
> > obvious if I understood the details of the gcc optimization phases, but
> > I doubt your average user (even the numerically aware ones) will know
> this
> > info either . . .
>
> Hmmm, I'm not sure this is a good example; Richard - maybe
> you have better example that demonstrate this; anyway,
> considering the transformation which handle
> (A1 * C1) - (A2 * C2) with A1, A2 or C1, C2 being the
> same or one. (taken from fold-const.c)
> Where C1 = C2 = -1 and A1 = A2
> Than (A1 * C1) - (A2 * C2) = +0.0
> and (A1 - A2) * C1 = -0.0
>
> Which is like -(X-Y) -> Y-X , right?
> The patch in http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00843.html
> list transformations which are currently under -unasfe-flag-optimizations
> and adequate for the new definition. It seems that signed zero is the only
> violation of IEEE we have and should mention in the definition.
I believe we may also inhibit or create underflow or overflow with
re-ordering for example
(X + C1) - C2 to X + (C1 - C2)
for X near FLT_MAX and C1 sufficiently large. Even transforming
X + Y - Y to X
may fail to propagate a NaN Y to the result.
For example in fold_binary we have
case MINUS_EXPR:
....
if ((! FLOAT_TYPE_P (type) || flag_unsafe_math_optimizations)
&& operand_equal_p (arg0, arg1, 0))
return fold_convert (type, integer_zero_node);
which should read || (!HONOR_NANS (mode) && !HONOR_INFINITIES (mode)
&& !HONOR_SIGNED_ZEROS (mode)).
Another example is the whole associate logic there:
associate:
/* In most languages, can't associate operations on floats through
parentheses. Rather than remember where the parentheses were, we
don't associate floats at all, unless the user has specified
-funsafe-math-optimizations. */
if (! FLOAT_TYPE_P (type) || flag_unsafe_math_optimizations)
{
tree var0, con0, lit0, minus_lit0;
tree var1, con1, lit1, minus_lit1;
Richard.
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs