[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

["jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #14 from jakub at gcc dot gnu dot org  2008-10-15 09:08 -------
The problem is that thread_across_edge figures out that the fabs (al[0] -
al[1])
< 1.e-5 test is unnecessary, always yields false for +-1.0, by substituting the
values in record_temporary_equivalences_from_stmts_at_dest, but doesn't
actually optimize all the computations to constants.  If the threading
duplicated block is used just for one constant, not two, then fab optimizes
the __builtin_pow call into a constant and dom2 optimizes the rest into a
constant.  But as we have two different constants leading to the same block,
nothing in GCC optimizes it out, and given -fno-signed-zeros and the testcase
very much depending on the sign of zeros, the outcome is different from what
the compiler expected.  While GCC perhaps could optimize:
  # cn_43 = PHI <-1.0e+0(3), 1.0e+0(9)>
  D.1267_44 = __builtin_pow (cn_43, 2.0e+0);
  D.1268_46 = 1.0e+0 - D.1267_44;
  D.1269_47 = __builtin_sqrt (D.1268_46);
into a constant with some smarter fab or dom hack for multiple constants, it
can't already optimize the following:
  D.1270_49 = __builtin_atan2 (D.1269_47, cn_43);
or
  D.1270_49 = __builtin_atan2 (0.0, cn_43);
because that yields different values for -1 and 1.  While even the partial
optimization would cure this testcase and is perhaps an useful enhancement,
I believe it is just wrong to compile this part of calculix with -ffast-math
and you get what you deserve.
`-fno-signed-zeros'
     Allow optimizations for floating point arithmetic that ignore the
     signedness of zero.  IEEE arithmetic specifies the behavior of
     distinct +0.0 and -0.0 values, which then prohibits simplification
     of expressions such as x+0.0 or 0.0*x (even with
     `-ffinite-math-only').  This option implies that the sign of a
     zero result isn't significant.
is quite clear and this testcase definitely relies on +0 vs. -0 difference
heavily.

So I'd say this should be closed as INVALID.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu dot org


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