On August 30, 2018 6:54:21 PM GMT+02:00, Martin Sebor <mse...@gmail.com> wrote: >On 08/30/2018 02:35 AM, Richard Biener wrote: >> On Thu, Aug 30, 2018 at 2:12 AM Martin Sebor <mse...@gmail.com> >wrote: >>> >>> The attached patch adds code to work harder to determine whether >>> the destination of an assignment involving MEM_REF is the same >>> as the destination of a prior strncpy call. The included test >>> case demonstrates when this situation comes up. During ccp, >>> dstbase and lhsbase returned by get_addr_base_and_unit_offset() >>> end up looking like this: >> >> "During CCP" means exactly when? The CCP lattice tracks copies >> so CCP should already know that _1 == _8. I suppose during >> substitute_and_fold then? But that replaces uses before folding >> the stmt. > >Yes, when ccp_finalize() performs the final substitution during >substitute_and_fold().
But then you shouldn't need the loop but at most look at the pointer SSA Def to get at the non-invariant ADDR_EXPR. Richard. >Martin > >> >> So I'm confused. >> >>> >>> _8 = &pb_3(D)->a; >>> _9 = _8; >>> _1 = _9; >>> strncpy (MEM_REF (&pb_3(D)->a), ...); >>> MEM[(struct S *)_1].a[n_7] = 0; >>> >>> so the loops follow the simple assignments until we get at >>> the ADDR_EXPR assigned to _8 which is the same as the strncpy >>> destination. >>> >>> Tested on x86_64-linux. >>> >>> Martin
