This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)


On Tue, Sep 18, 2018 at 8:58 PM Jeff Law <law@redhat.com> wrote:
>
> On 9/18/18 11:12 AM, Martin Sebor wrote:
>
> >> My bad.  Sigh. CCP doesn't track copies, just constants, so there's not
> >> going to be any data structure you can exploit.  And I don't think
> >> there's a value number you can use to determine the two objects are the
> >> same.
> >>
> >> Hmm, let's back up a bit, what is does the relevant part of the IL look
> >> like before CCP?  Is the real problem here that we have unpropagated
> >> copies lying around in the IL?  Hmm, more likely the IL looksl ike:
> >>
> >>    _8 = &pb_3(D)->a;
> >>    _9 = _8;
> >>    _1 = _9;
> >>    strncpy (MEM_REF (&pb_3(D)->a), ...);
> >>    MEM[(struct S *)_1].a[n_7] = 0;
> >
> > Yes, that is what the folder sees while the strncpy call is
> > being transformed/folded by ccp.  The MEM_REF is folded just
> > after the strncpy call and that's when it's transformed into
> >
> >   MEM[(struct S *)_8].a[n_7] = 0;
> >
> > (The assignments to _1 and _9 don't get removed until after
> > the dom walk finishes).
> >
> >>
> >> If we were to propagate the copies out we'd at best have:
> >>
> >>    _8 = &pb_3(D)->a;
> >>    strncpy (MEM_REF (&pb_3(D)->a), ...);
> >>    MEM[(struct S *)_8].a[n_7] = 0;
> >>
> >>
> >> Is that in a form you can handle?  Or would we also need to forward
> >> propagate the address computation into the use of _8?
> >
> > The above works as long as we look at the def_stmt of _8 in
> > the MEM_REF (we currently don't).  That's also what the last
> > iteration of the loop does.  In this case (with _8) it would
> > be discovered in the first iteration, so the loop could be
> > replaced by a simple if statement.
> >
> > But I'm not sure I understand the concern with the loop.  Is
> > it that we are looping at all, i.e., the cost?  Or that ccp
> > is doing something wrong or suboptimal? (Should have
> > propagated the value of _8 earlier?)
> I suspect it's more a concern that things like copies are typically
> propagated away.   So their existence in the IL (and consequently your
> need to handle them) raises the question "has something else failed to
> do its job earlier".
>
> During which of the CCP passes is this happening?  Can we pull the
> warning out of the folder (even if that means having a distinct warning
> pass over the IL?)

Note CCP also propagates copies.

Richard.

>
> Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]