[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math

2021-08-13 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Andrew Pinski  ---
Fixed in GCC 6 by r6-4229.

[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math

2014-05-09 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119

--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Tricky case, but fold also handles REALPART / IMAGPART of +, - and conjugate
and of a cexpi call.  Of course that may not matter in the end, as
easily decompose probably doesn't apply to those simplifications (as shown
here).


[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math

2014-05-09 Thread glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119

--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
 Tricky case, but fold also handles REALPART / IMAGPART of +, - and conjugate
 and of a cexpi call.  Of course that may not matter in the end, as
 easily decompose probably doesn't apply to those simplifications (as shown
 here).

That was my point. Replacing cexp with exp*expi does not gain anything in
itself, the hope is that either exp or expi gets further simplifications
(possibly because it is a constant). In most (of the rare) cases where the
folding of realpart of + helps, we probably missed an optimization where we
could have folded + to something better (likely a complex_expr in the end).

Anyway, except possibly for the constant folding, the transformation should
eventually move to gimple-only where there won't be those save_expr issues.


[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math

2014-05-09 Thread rguenther at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119

--- Comment #6 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 9 May 2014, glisse at gcc dot gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119
 
 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
 (In reply to Richard Biener from comment #4)
  Tricky case, but fold also handles REALPART / IMAGPART of +, - and conjugate
  and of a cexpi call.  Of course that may not matter in the end, as
  easily decompose probably doesn't apply to those simplifications (as shown
  here).
 
 That was my point. Replacing cexp with exp*expi does not gain anything in
 itself, the hope is that either exp or expi gets further simplifications
 (possibly because it is a constant). In most (of the rare) cases where the
 folding of realpart of + helps, we probably missed an optimization where we
 could have folded + to something better (likely a complex_expr in the end).
 
 Anyway, except possibly for the constant folding, the transformation should
 eventually move to gimple-only where there won't be those save_expr issues.

Of course.


[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math

2014-05-08 Thread glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119

--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
But arg0 = builtin_save_expr (arg0); would prevent from folding REALPART_EXPR.
Looking at the fold_unary_loc transforms on REALPART_EXPR, I think it is fine
to restrict the special fast-math treatment in fold_builtin_cexp to the case
where arg0 is a COMPLEX_EXPR. Then we can extract the arguments directly with
TREE_OPERAND and the existing save_expr are enough.

@@ -7853,7 +7853,7 @@ fold_builtin_cexp (location_t loc, tree
   /* In case we can easily decompose real and imaginary parts split cexp
  to exp (r) * cexpi (i).  */
   if (flag_unsafe_math_optimizations
-   realp)
+   TREE_CODE (arg0) == COMPLEX_EXPR)
 {
   tree rfn, rcall, icall;

@@ -7861,9 +7861,8 @@ fold_builtin_cexp (location_t loc, tree
   if (!rfn)
 return NULL_TREE;

-  imagp = fold_unary_loc (loc, IMAGPART_EXPR, rtype, arg0);
-  if (!imagp)
-return NULL_TREE;
+  realp = TREE_OPERAND (arg0, 0);
+  imagp = TREE_OPERAND (arg0, 1);

   icall = build_call_expr_loc (loc, ifn, 1, imagp);
   icall = builtin_save_expr (icall);