https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mpolacek at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed| |2022-08-15
Keywords| |needs-bisection
Ever confirmed|0 |1
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
Applying pattern match.pd:5769, generic-match.cc:14472
...
that's the following pattern which GCC 12 doesn't have
/* From fold_binary_op_with_conditional_arg handle the case of
rewriting (a ? b : c) > d to a ? (b > d) : (c > d) when the
compares simplify. */
(for cmp (simple_comparison)
(simplify
(cmp:c (cond @0 @1 @2) @3)
/* Do not move possibly trapping operations into the conditional as this
pessimizes code and causes gimplification issues when applied late. */
(if (!FLOAT_TYPE_P (TREE_TYPE (@3))
|| operation_could_trap_p (cmp, true, false, @3))
(cond @0 (cmp! @1 @3) (cmp! @2 @3)))))
the testcase is essentially a degenerate case of this, applying the
pattern recursively.
The testcase is a bit too large to easily follow what happens, cutting
some lines in the middle shows we are eventually producing
0, 0 ? nr_cpu_ids == 0 && ((nr_cpu_ids & 7) == 0 && (nr_cpu_ids == 0 &&
((nr_cpu_ids & 5) == 0 && (nr_cpu_ids == 0 && ((nr_cpu_ids & 3) == 0 &&
(nr_cpu_ids + -1 & 1) != 0))))) : 0 ? 2 : 1;
not sure why we don't fold the (0, 0) ? ..., that seems to be a "bug" of
fully folding in the C frontend? We do simplify 0 ? ... just fine.
Supposedly COMPOUND_EXPRs are never constant folded?
