From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 941 invoked by alias); 31 Aug 2018 10:07:36 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 930 invoked by uid 89); 31 Aug 2018 10:07:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-lj1-f194.google.com Received: from mail-lj1-f194.google.com (HELO mail-lj1-f194.google.com) (209.85.208.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Aug 2018 10:07:34 +0000 Received: by mail-lj1-f194.google.com with SMTP id s12-v6so9662628ljj.0 for ; Fri, 31 Aug 2018 03:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vavlmbAeaXvITseolo6LF9IuOFAV8DVXBlMikXsvIJg=; b=XIC+QTn8NPKLZhCbdpRvISWtiqVll3Qh7yiTGiQjOBr+B2vOEm+ygwKeNhGD1zR94w MAM6/jgNFqjKFfNFyW1UHmzZhiiKoBV6oz8gNfWYNLALplgzhyw1dcPJrGeUW0g2ESoG ftoJHNeOmYhBcOACC/a3Q50IWuAKJ/99F7xV2DngC+B4CUlRqfB9Wg9BSy0wAXOxPVUT fg6lha5P33TlLZkS0sLIMbaZV+UdVypaAeEf0sFQUfmAIzn60jhrp/JOlGFpTYBIqt12 H99415JMeET80bt0cl44R+dF9XJzOafhopp/3I9DnIjZwbCTSTmuA8cjOQi74e7Mn/tv kcpQ== MIME-Version: 1.0 References: <6c2126fa-32b3-693b-e3da-cf70391710bf@gmail.com> <346c0950-ac9e-b7b4-799f-a8b661f7d55b@gmail.com> <9ca1c7dc-041a-3e15-a191-34d16a68aa2f@gmail.com> In-Reply-To: <9ca1c7dc-041a-3e15-a191-34d16a68aa2f@gmail.com> From: Richard Biener Date: Fri, 31 Aug 2018 10:07:00 -0000 Message-ID: Subject: Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561) To: Martin Sebor Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg02020.txt.bz2 On Thu, Aug 30, 2018 at 7:39 PM Martin Sebor wrote: > > On 08/30/2018 11:22 AM, Richard Biener wrote: > > On August 30, 2018 6:54:21 PM GMT+02:00, Martin Sebor wrote: > >> On 08/30/2018 02:35 AM, Richard Biener wrote: > >>> On Thu, Aug 30, 2018 at 2:12 AM Martin Sebor > >> 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. > > I don't follow. Are you suggesting to compare > SSA_NAME_DEF_STMT (dstbase) to SSA_NAME_DEF_STMT (lhsbase) for > equality? They're not equal. No. > The first loop iterates once and retrieves > > 1. _8 = &pb_3(D)->a; > > The second loop iterates three times and retrieves: > > 1. _1 = _9 > 2. _9 = _8 > 3. _8 = &pb_3(D)->a; > > How do I get from _1 to &pb_3(D)->a without iterating? Or are > you saying to still iterate but compare the SSA_NAME_DEF_STMT? I say you should retrieve _8 = &pb_3(D)->a immediately since the copies should be propagated out at this stage. > Martin > > > > > 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 > > >