This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Fix PR28684


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]