This is the mail archive of the gcc-bugs@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]

[Bug tree-optimization/17578] Missed optimization--failure of gcc.c-torture/execute/ieee/compare-fp-3.c at -O1 and above


------- Additional Comments From danglin at gcc dot gnu dot org  2004-09-23 03:17 -------
> > The generated code for this function is ok.  It's just not optimized.
> > As far as I can tell, neither comparison should trap, so -ftrapping-math
> > shouldn't affect the optimization.
>
> I take this back.  The compares can trap if x or y is a signalling NaN.
> Thus, the compares can't be optimized without -fno-trapping-math.

It seems that the default for flag_signaling_nans is 0.  The equality and
inequality operators are not supposed to trap on a quiet NaN.  Thus, test1
should be optimized without the -fno-trapping_math option.  See the node
description for EQ_EXPR and NE_EXPR in doc/c-tree.texi.  Currently, it is
not being optimized at the tree level on either hppa-unknown-linux-gnu or
i686-pc-linux-gnu.

On the otherhand, LT_EXPR, LE_EXPR, GT_EXPR, GE_EXPR and possibly LTGT_EXPR
can cause an invalid exception if one of the operands is a quiet NaN.  Thus,
the following two functions shouldn't be optimized without -fno-trapping_math:

void
test2 (float x, float y)
{
  if ((x<y) && (x>y))
    link_error0();
}

void
test3 (float x, float y)
{
  if ((x<y) && (y<x))
    link_error0();
}

However, these two functions are being optimized at the tree level.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17578


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