On Tue, 11 Aug 2015, Marc Glisse wrote: > On Tue, 11 Aug 2015, Richard Biener wrote: > > > On Tue, 11 Aug 2015, Marc Glisse wrote: > > > > > On Wed, 29 Jul 2015, Richard Biener wrote: > > > > > > > The following fixes PR67053 by more closely mirror what fold_binary()s > > > > STRIP_NOPS does to avoid the C++ FE constexpr code to regress. > > > > > > > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > > > > > > > Yes, I'm thinking on an automated way to more closely mirror > > > > STRIP_[SIGN_]NOPS behavior (on toplevel args). > > > > > > As far as I can see, you are not currently checking that these conversions > > > are > > > NOPs. I didn't test, but I am afraid this may simplify (char)p1==(char)p2 > > > to > > > false a bit too quickly. > > > > I'm relying on our restrictions on conversions of pointers to integers > > which requires same-precision (and thus always NOP-style) here. > > Indeed. I had tested yesterday with an older gcc that we were generating the > problematic pattern (with conversion from pointer to char), but I can't > reproduce today, so I guess I had typoed something :-(
Actually I now see some "special" handling of targets like m32c which are allowed direct pointer to sizetype conversion even if that is a truncation. For m32c IIRC pointer types are 24bit and sizetype is 16bit. So I suppose I have to add that nop-conversion checks anyway :/ Richard.
