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).
