On Mon, Mar 18, 2013 at 12:06 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
> 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)
Hmm, I see we don't even have the code available in
fold_cond_expr_with_comparison.
So use 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
|| VECTOR_TYPE_P (type)
|| (strcmp (lang_hooks.name, "GNU C++") != 0
&& strcmp (lang_hooks.name, "GNU Objective-C++") != 0)
|| ! maybe_lvalue_p (arg1)
|| ! maybe_lvalue_p (arg2)))
err - there isn't a VECTOR_TYPE_P predicate - time to add one ;)
Thanks,
Richard.
> --
> Marc Glisse
