[Bug c++/49165] [4.3/4.4/4.5/4.6/4.7 Regression] ICE on for-loop/throw combination

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49165

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-26 08:47:36 UTC ---
No.
Both arms shouldn't be VOID_TYPE_P, otherwise the COND_EXPR would be
VOID_TYPE_P too and we really shouldn't be using the COND_EXPR's value.
The problem is that the C++ FE gives us
COND_EXPR with bool type (or some other type), with one arm the same type and
the other arm THROW_EXPR (i.e. VOID_TYPE_P).
The gimplifier is already aware of this and handles it right:
      /* Build the new then clause, `tmp = then_;'.  But don't build the
         assignment if the value is void; in C++ it can be if it's a throw.  */
      if (!VOID_TYPE_P (TREE_TYPE (then_)))
        TREE_OPERAND (expr, 1) = build2 (MODIFY_EXPR, type, tmp, then_);

      /* Similarly, build the new else clause, `tmp = else_;'.  */
      if (!VOID_TYPE_P (TREE_TYPE (else_)))
        TREE_OPERAND (expr, 2) = build2 (MODIFY_EXPR, type, tmp, else_);
just shortcut_cond_r didn't handle it well (it created
COND_EXPR with void type throw ? goto L1 : goto L2).