On Mon, 18 Mar 2013, Richard Biener wrote:
On Mon, Mar 18, 2013 at 11:27 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
On Mon, 18 Mar 2013, Richard Biener wrote:
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.
Hmm, there isn't one. There is just a block of code that is disabled when
the compiler is not certain that the result is not an lvalue. And the
arguments it can use to prove that are:
* we are in gimple form
* we are not doing C++
* one of the alternatives is not an lvalue
* (new) it is a vec_cond_expr
Apart from changing TREE_CODE == VEC_COND_EXPR to TREE_CODE != COND_EXPR,
I am not sure what to change.
(Looking at the patch, I may have forgotten to check for side effects
somewhere, the tests needed are not exactly the same as for COND_EXPR
since VEC_COND_EXPR is not lazy, I'll check that before resubmitting)
--
Marc Glisse
