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)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 30 Aug 2018 19:22:36 +0200
- Subject: Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)
- References: <6c2126fa-32b3-693b-e3da-cf70391710bf@gmail.com> <CAFiYyc2g_ESGSoGiu8D3ZCRf8NOWJ5btNuJjStYC5RGP=z-OUA@mail.gmail.com> <346c0950-ac9e-b7b4-799f-a8b661f7d55b@gmail.com>
On August 30, 2018 6:54:21 PM GMT+02:00, Martin Sebor <msebor@gmail.com> wrote:
>On 08/30/2018 02:35 AM, Richard Biener wrote:
>> On Thu, Aug 30, 2018 at 2:12 AM Martin Sebor <msebor@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