This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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