Hello Jason, after a longer delay the answer to your question.
2015-08-03 17:39 GMT+02:00 Jason Merrill <ja...@redhat.com>: > On 08/03/2015 05:42 AM, Kai Tietz wrote: >> >> 2015-08-03 5:49 GMT+02:00 Jason Merrill <ja...@redhat.com>: >>> >>> 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 > > > Which testcase is this? It is the g++.dg/ext/vector20.C testcase. IIRC I mentioned this testcase already earlier as reference, but I might be wrong here. >> 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 ...) { ... }). > > > How could a PLUS_EXPR be considered a reduced constant, regardless of where > the cast is? Of course it is just possible to sink out a cast from PLUS_EXPR, in pretty few circumstance (eg. on constants if both types just differ in const-attribute, if conversion is no view-convert). >>>> 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. > > > I wasn't suggesting we ignore it, we should be able to change the type of > the vector_cst. Well, the vector_cst we can change type, but this wouldn't help AFAICS. As there is still one cast surviving within PLUS_EXPR for the other operand. So the way to solve it would be to move such conversion out of the expression. For integer-scalars we do this, and for some floating-points too. So it might be something we don't handle for operations with vector-type. >> 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). > > > Right. But really this should happen in convert.c, it shouldn't be specific > to C++. Hmm, maybe. But isn't one of our different goals to move such implicit code-modification to match.pd instead? > Jason > Kai