On Mon, Mar 18, 2013 at 11:27 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Mon, 18 Mar 2013, Richard Biener wrote: > >>> 2013-03-17 Marc Glisse <marc.gli...@inria.fr> >>> >>> gcc/ >>> * fold-const.c (fold_cond_expr_with_comparison): Use >>> build_zero_cst. >>> VEC_COND_EXPR cannot be lvalues. >>> (fold_ternary_loc) <VEC_COND_EXPR>: Call >>> fold_cond_expr_with_comparison. >>> >>> gcc/cp/ >>> * call.c (build_conditional_expr_1): Fold VEC_COND_EXPR. >>> >>> gcc/testsuite/ >>> * g++.dg/ext/vector21.C: New testcase. > > >>> @@ -4662,21 +4662,22 @@ fold_cond_expr_with_comparison (location >>> expressions will be false, so all four give B. The min() >>> and max() versions would give a NaN instead. */ >>> if (!HONOR_SIGNED_ZEROS (TYPE_MODE (type)) >>> && operand_equal_for_comparison_p (arg01, arg2, arg00) >>> /* Avoid these transformations if the COND_EXPR may be used >>> as an lvalue in the C++ front-end. PR c++/19199. */ >>> && (in_gimple_form >>> || (strcmp (lang_hooks.name, "GNU C++") != 0 >>> && strcmp (lang_hooks.name, "GNU Objective-C++") != 0) >>> || ! maybe_lvalue_p (arg1) >>> - || ! maybe_lvalue_p (arg2))) >>> + || ! maybe_lvalue_p (arg2) >>> + || TREE_CODE (TREE_TYPE (arg1)) == VECTOR_TYPE)) >> >> >> You mean that the VEC_COND_EXPRs can never be used as an lvalue in >> the C++ frontend? > > > Yes, as I mention in the ChangeLog. Not just the C++ front-end, it never > makes sense to use a VEC_COND_EXPR as an lvalue, it really is just a ternary > variant of BIT_AND_EXPR.
Then please add a && TREE_CODE == COND_EXPR around the code handling only COND_EXPRs instead. Richard. > >> Btw, instead of copying this whole block I'd prefer >> >> case COND_EXPR: >> case VEC_COND_EXPR: >> ... common cases... >> >> /* ??? Fixup the code below for VEC_COND_EXRP. */ >> if (code == VEC_COND_EXPR) >> break; > > > Makes sense, I'll rework the patch. > > Thanks, > > -- > Marc Glisse
