From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90578 invoked by alias); 30 Nov 2018 08:05:14 -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 90566 invoked by uid 89); 30 Nov 2018 08:05:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:Fri, HX-Gm-Message-State:sk:aEWYdWt, Hx-languages-length:2810 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, 30 Nov 2018 08:05:11 +0000 Received: by mail-lj1-f194.google.com with SMTP id v15-v6so4144758ljh.13 for ; Fri, 30 Nov 2018 00:05:10 -0800 (PST) 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=l3/XRckMfdAFXzLk0ZsKQPsSQbjJCUz1NyknX+qcklQ=; b=P2T4dPU+XYs1fAo6N1fOGwyQYHSbjBu1Inh9OEAOGNz9sYaHrbIPisx692SulPDYCm ZLD+ME0HmTsuUwfVmS7QgEomY5wTS+DTgF8mHrNUXb8jjDamKjTp5Armr3k24mvRAsqU 5oqd1Z29e2MNpI9jmMKQR5QVd/xmEsbN5u/VijM8fzPBPAAwfP+5TVdn3CpoyOUNZKdG QZOolYscdAZ3yQyA+5Wd2ZNbOTifufFlHn0h/7ApLAiID4Qn09ISXHsDQLkdLm5zN21u cfXOs3mUA0q+olktiLW6w0gwqu/yMkpszSuvzCl5GqFgJu761KOlDIWS+gIXYxv/wObn jdJQ== MIME-Version: 1.0 References: <88de1ee3-6ee4-d8d9-3e57-3a42474a4169@redhat.com> <27235a6d-6f2c-1f2d-d456-d4cd9b941894@redhat.com> <23ea3d13-d9c5-1b02-f01c-d2a0e11f3a10@redhat.com> <9e3f6d62-47b9-b80f-b8ac-5711628579c5@redhat.com> <09ce3b57-33a3-86ae-1308-39fd02f25228@gmail.com> <1437ae83-c0c2-e18f-0dc8-92717c2fdcfe@gmail.com> <8a346afb-382f-cac9-a2b7-7107ef678dee@redhat.com> In-Reply-To: From: Richard Biener Date: Fri, 30 Nov 2018 08:05:00 -0000 Message-ID: Subject: Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028) To: Jeff Law Cc: Martin Sebor , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg02531.txt.bz2 On Fri, Nov 30, 2018 at 3:02 AM Jeff Law wrote: > > On 11/29/18 4:43 PM, Martin Sebor wrote: > >> The fallout on existing tests is minimal. What's more concerning is > >> that it doesn't actually pass the new test from Martin's original > >> submission. We get bogus warnings. > >> > >> At least part of the problem is weakness in maybe_diag_stxncpy_trunc. > >> It can't handle something like this: > >> > >> test_literal (char * d, struct S * s) > >> { > >> strncpy (d, "1234567890", 3); > >> _1 = d + 3; > >> *_1 = 0; > >> } > >> > >> > >> Note the pointer arithmetic between the strncpy and storing the NUL > >> terminator. I already said the way the code looks for the next stmt is totally backwards... Oh, and I also already voiced my concerns about emitting warnings from folding code, did I? ... So, let's suppose we delay folding of (builtin [string]) calls to some first special pass that also diagnoses those issues. One obvious place to place this pass would be where we now do the early object-size pass. In fact we might want to merge the object-size pass with the strlen pass because they sound so much related. This pass would then fold the calls and set some cfun->gimple_df->after_call_warnings flag we could test in the folder (similar to how we have avoid_folding_inline_builtin ()). This placement ensures that we already got functions early inlined (albeit in "early optimized" form but with their diagnostics already been emitted). This is of course all GCC 10 material. > > Right. I'm less concerned about this case because it involves > > a literal that's obviously longer than the destination but it > > would be nice if the suppression worked here as well in case > > the literal comes from macro expansion. It will require > > another tweak. > OK. If this isn't at the core of the regression BZ, then xfailing those > particular cases and coming back to them is fine. > > > > > But the test from my patch passes with the changes to calls.c > > from my patch, so that's an improvement. > > > > I have done the test suite cleanup in the attached patch. It > > was indeed minimal -- not sure why I saw so many failures with > > my initial approach. > Richi's does the folding as part of gimple lowering. So it's still > pretty early -- basically it ends up hitting just a few tests that are > looking for folded stuff in the .gimple dump. > > I had actually targeted this patch as one to work through and try to get > resolved today. Kind of funny that we were poking at it at the same time. > > > > > > I can submit a patch to handle the literal case above as > > a followup unless you would prefer it done at the same time. > Follow-up is fine by me. > > jeff