[Bug middle-end/61119] gcc miscompiles code using cexp when using -ffast-math
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
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
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
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
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);