https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2019-10-11
CC| |iii at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |10.0
Ever confirmed|0 |1
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r276659.
The fix for this ICE is easy:
--- gcc/tree-eh.c.jj 2019-10-07 17:30:31.028153702 +0200
+++ gcc/tree-eh.c 2019-10-11 11:46:37.376774860 +0200
@@ -2615,7 +2615,7 @@ tree_could_trap_p (tree expr)
return false;
/* For COND_EXPR and VEC_COND_EXPR only the condition may trap. */
- if (TREE_CODE (expr) == COND_EXPR || TREE_CODE (expr) == VEC_COND_EXPR)
+ while (TREE_CODE (expr) == COND_EXPR || TREE_CODE (expr) == VEC_COND_EXPR)
expr = TREE_OPERAND (expr, 0);
code = TREE_CODE (expr);
though I'm a little bit worried about the tree-ssa-sccvn.c's
operation_could_trap_helper_p call, whether it can't call it on
COND_EXPR/VEC_COND_EXPR; while there is no assert in
operation_could_trap_helper_p for COND_EXPR/VEC_COND_EXPR, if it is ever
called, it might not give the right answer. Guess for those fp_operation would
be whether the second/third operand and lhs are floating, which might not be
related to whether condition is actually a floating point operation.
Anyway, will handle the above part and defer the rest to Ilya.
