2015-08-03 5:49 GMT+02:00 Jason Merrill <[email protected]>:
> On 07/31/2015 05:54 PM, Kai Tietz wrote:
>>
>> The "STRIP_NOPS-requirement in 'reduced_constant_expression_p'" I could
>> remove, but for one case in constexpr. Without folding we don't do
>> type-sinking/raising.
>
>
> Right.
>
>> So binary/unary operations might be containing cast, which were in the
>> past unexpected.
>
>
> Why aren't the casts folded away?
On such cast constructs, as for this vector-sample, we can't fold away
the cast chain. The difference here to none-delayed-folding branch is
that the cast isn't moved out of the plus-expr. What we see now is
(plus ((vec) (const vector ...) { .... }), ...). Before we had (vec)
(plus (const vector ...) { ... }).
>> On verify_constant we check by reduced_constant_expression_p, if value is
>> a constant. We don't handle here, that NOP_EXPRs are something we want to
>> look through here, as it doesn't change anything if this is a constant, or
>> not.
>
>
> NOPs around constants should have been folded away by the time we get there.
Not in this cases, as the we actually have here a switch from const to
none-const. So there is an attribute-change, which we can't ignore in
general. But I agree that for constexpr's we could special case cast
from const to none-const (as required in expressions like const vec v
= v + 1).
> Jason
>
Kai
