From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59006 invoked by alias); 19 Nov 2018 16:27:06 -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 57752 invoked by uid 89); 19 Nov 2018 16:27:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:ee66fcd, planing X-HELO: mail-qk1-f193.google.com Received: from mail-qk1-f193.google.com (HELO mail-qk1-f193.google.com) (209.85.222.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Nov 2018 16:27:04 +0000 Received: by mail-qk1-f193.google.com with SMTP id d19so49514365qkg.5 for ; Mon, 19 Nov 2018 08:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=sxtr6w8W8iuRU0AjA+BnMxqWIbCS8HvZK/dL02gGuqM=; b=q8hTwH9/s6XcPVarl5BUdN2/xg/rro1zzxWCxr5e0Wysx4dLRM+U2oKiURm6WcGfxy zg1knMbTdPHh18ycRwbF1ltbbqRLzJ7x13PO5hMdQTZuYQeB6pqKYsY0VOidLoc0UwPh fyEMkCdU3PXXvkqdFJlKkmKjHMT4ZT3NS5i7Qw8oG4Y+zXwsbS8yG9t6ZLy1tSKdppAc PTfu48diA13m70DQ4j5XaWooR4e26N0WyhN6QfB7sqj4r8S0kPl3JseYA+LsDNN6b0QU 2tDvq7JhtcTMQaQFD3GRA4RvFCp2TFCnI/xLH1VTGt+Hglp68nVEREhrz1NJxgSu47C7 MZMQ== Return-Path: Received: from localhost.localdomain (97-118-99-160.hlrn.qwest.net. [97.118.99.160]) by smtp.gmail.com with ESMTPSA id w52sm24633380qtc.51.2018.11.19.08.27.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 08:27:01 -0800 (PST) From: Martin Sebor Subject: Re: [PING #4] [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561) To: Richard Biener References: <6c2126fa-32b3-693b-e3da-cf70391710bf@gmail.com> <1555c8f2-019a-1164-d1cc-650b78230c63@redhat.com> <26c29db3-6e0c-7df4-c779-cf01e958c654@gmail.com> <51ebb626-7207-edf8-9a70-c1ec525d24f3@gmail.com> <16290c2f-6203-7709-e7ec-1d56de6c20a2@redhat.com> <3911c594-d8f8-d2d5-0d6f-70c62275ce12@redhat.com> <4aa12e16-f1ab-4311-ac4e-0050ce3c9218@gmail.com> <23ca6dca-8887-77ba-03fe-fdbb5639f2dd@gmail.com> <6ea88a1b-849f-a781-6963-72cc205e433f@gmail.com> <6034b402-e7f6-530e-6f0f-da1060ea165f@gmail.com> <7b12ea89-9b24-bf38-a8be-05cb51dbbadd@gmail.com> Cc: Jeff Law , GCC Patches Message-ID: <095e37eb-d77c-4ce1-dc93-84d6becc3268@gmail.com> Date: Mon, 19 Nov 2018 16:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg01644.txt.bz2 On 11/16/2018 01:46 AM, Richard Biener wrote: > On Fri, Nov 16, 2018 at 4:09 AM Martin Sebor wrote: >> >> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01934.html >> >> Do I need to change something in this patch to make it acceptable >> or should I assume we will leave this bug in GCC unfixed? > > So the issue is the next_stmt handling because for the _next_ stmt > we did not yet replace uses with lattice values. This information > was missing all the time along (and absent from patch context). > > I notice the next_stmt handling is incredibly fragile and it doesn't > even check the store you identify as thouching the same object > writes a '\0', nor does it verify the store writes to a position after > the strncpy accessed area (but eventually anywhere is OK...). Yes, this is being tracked in bug 84396. I have been planing to tighten it up to check that it is, in fact, the NUL character being inserted but other things have been getting in the way (like trying to fix this bug). > So I really wonder why there's the restriction on 1:1 equality of the > base. That relies on proper CSE (as you saw and tried to work-around > in your patch) and more. > > So what I'd do is the attached. Apply more leeway (and less at the > same time) and restrict it to stores from zero but allow any aliasing > one. One could build up more precision by, instead of using > ptr_may_alias_ref_p use refs_may_alias_p and build up a ao_ref > for the strncpy destination using ao_ref_from_ptr_and_size, but > I didn't bother to figure out what constraint on len the function > computed up to this point. > > The patch fixes the testcase. It does, but it also introduces two regressions into the test suite (false negatives). The code your patch removes is there to handle these cases. I'll look into your suggestion to use refs_may_alias_p to avoid these regressions. Martin PS With the suggested patch GCC fails to detect the following: struct A { char str[3]; }; struct B { struct A a[3]; int i; }; struct C { struct B b[3]; int i; }; void f (struct B *p, const char *s) { // write into p->a[0]: __builtin_strncpy (p->a[0].str, s, sizeof p->a[0].str); // write into p->a[1]: p->a[1].str[sizeof p->a[1].str - 1] = 0; }