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

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like the gimplification is not handling SAVE_EXPR correctly:
    complex double val = COMPLEX_EXPR <SAVE_EXPR <__builtin_exp ((double) fun
())> * REALPART_EXPR <SAVE_EXPR <__builtin_cexpi (fun ();, 0.0)>>, SAVE_EXPR
<__builtin_exp ((double) fun ())> * IMAGPART_EXPR <SAVE_EXPR <__builtin_cexpi
(fun ();, 0.0)>>>;

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

[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);

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

[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

[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

[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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61119

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed in GCC 6 by r6-4229.