On Tue, Jan 24, 2017 at 11:54:09AM +0100, Richard Biener wrote:
> > Please note that say for:
> > struct S { int : 1; int a : 3; int : 1; int b : 2; };
> >
> > int
> > foo (S a, S b)
> > {
> > return a.a == b.a && a.b == b.b;
> > }
> >
> > (haven't tried to turn that into a constexpr testcase, but shouldn't be
> > hard), the folding creates
> > ((BIT_FIELD_REF <a, 8, 0> ^ BIT_FIELD_REF <b, 8, 0>) & 110) == 0
> > out of that. So unless we DTRT (i.e. save constexpr bodies before
> > cp_fold for constexpr evaluation purposes), the workaround would need
> > to handle this properly (basically pattern recognize whatever the
> > folding may create for the bitfield tests and undo it or track bitwise which
> > bits are known to be constexpr and which bits are undefined and during
> > the BIT_AND_EXPR testing verify it isn't asking for any bits that aren't
> > constexpr). And that there can be multiple bitfields covered by the same
> > BIT_FIELD_REF.
>
> Just chiming in to say (again) this folding is bad and/or premature. A way
> to avoid it for C++ would be to move it to gimplification? It won't
> ever trigger
> on GIMPLE. Not that I like gimplification specific "simplifications" too
> much.
Sure, it won't hurt to move this optimizations later if it will not be much
harder, on the other side, there are many other reasons why constexpr
evaluation should be done on unfolded bodies (e.g., if there is an out of
bound array access or some other undefined behavior somewhere where it is
folded away (say (i = 5; j = arr[i] & 0;) on int arr[3];), C++ should still
error out
during constexpr evaluation of it, while with folded trees it just won't see
it.
Jakub
