[Bug middle-end/92063] [10 Regression] ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c

[jakub at gcc dot gnu.org]

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.