This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR67053
- From: Richard Biener <rguenther at suse dot de>
- To: gcc-patches at gcc dot gnu dot org
- Date: Tue, 11 Aug 2015 10:45:39 +0200 (CEST)
- Subject: Re: [PATCH] Fix PR67053
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1507291622240 dot 19642 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 20 dot 1508110245080 dot 5830 at laptop-mg dot saclay dot inria dot fr> <alpine dot LSU dot 2 dot 11 dot 1508110946310 dot 19642 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 20 dot 1508111016440 dot 1659 at laptop-mg dot saclay dot inria dot fr>
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.