On Thu, Mar 4, 2021 at 1:23 AM Ivan Sučić via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Hi,
> The patch solves the bug when in ifcombine are comparisons like <= and >=
> combined. I removed the trap check for last statement and that doesn't break
> the solution for bug 61383. In fold-const.c i removed the trap checks becase
> combining comparisons doesn't introduce new traps. I tested my patch on wsl2
> debain and it doesn't have more failed tests then without my patch. Maybe the
> only problem with testing is that i get error tcl error sourcing
> gcc/testsuite/gcc.misc-tests/linkage.exp. That error I get without my patch,
> too. I hope you will accept my patch.
diff --git a/ChangeLog b/ChangeLog
index 6c07275d2b4..29176bf9607 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2021-03-03 Ivan Sucic <suci...@outlook.com>
newline missing
+ PR 53806
should be
<tab>PR tree-optimization/53806
+ * tree-ssa-ifcombine.c: Checking trap not for
+ last statement
should be
<tab>* tree-ssa-ifcombine.c (bb_no_side_effects_p): Checking trap
<tab>not for last statement.
+ * fold-const.c: The comparison combine makes
+ new comparison correct and the trap check is
+ not required.
+ * ssa-ifcombine-14.c: Testcase for if combine
+ comparisons of double type.
we are no longer editing ChangeLog files manually, instead the
changelog entry is now embedded
within the git commit message and automatically transfered. So please
for further submissions
use git format-patch which will include the commit message as well.
diff --git a/gcc/tree-ssa-ifcombine.c b/gcc/tree-ssa-ifcombine.c
index 21a70f4386d..f2abaf18342 100644
--- a/gcc/tree-ssa-ifcombine.c
+++ b/gcc/tree-ssa-ifcombine.c
@@ -125,7 +125,8 @@ bb_no_side_effects_p (basic_block bb)
if (gimple_has_side_effects (stmt)
|| gimple_uses_undefined_value_p (stmt)
- || gimple_could_trap_p (stmt)
+ /* Last statement is taken care by combining ifs */
+ || (!gsi_one_before_end_p (gsi) && gimple_could_trap_p (stmt))
|| gimple_vuse (stmt)
/* const calls don't match any of the above, yet they could
still have some side-effects - they could contain
might be easier to start the loop from the end of the BB and skip
a gimple-cond if it appears there.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 3744e4c2c2d..a83c98014fb 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -2860,40 +2860,6 @@ combine_comparisons (location_t loc,
else if (compcode == COMPCODE_ORD)
compcode = COMPCODE_TRUE;
}
- else if (flag_trapping_math)
- {
- /* Check that the original operation and the optimized ones will trap
- under the same condition. */
- bool ltrap = (lcompcode & COMPCODE_UNORD) == 0
...
- /* If the comparison was short-circuited, and only the RHS
- trapped, we may now generate a spurious trap. */
- if (rtrap && !ltrap
- && (code == TRUTH_ANDIF_EXPR || code == TRUTH_ORIF_EXPR))
- return NULL_TREE;
-
- /* If we changed the conditions that cause a trap, we lose. */
- if ((ltrap || rtrap) != trap)
- return NULL_TREE;
- }
if (compcode == COMPCODE_TRUE)
return constant_boolean_node (true, truth_type);
I don't think removing all code is OK since it would
allow combining x == y || x > y to x >= y which may
trap. The bugreport suggests to alter the last
test to something like
if (trap && !ltrap && !rtrap)
return NULL_TREE;
thus if we manage to remove a trap (!trap) the transform
is OK.
Thanks,
Richard.
