From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52629 invoked by alias); 7 Nov 2018 21:28:30 -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 52591 invoked by uid 89); 7 Nov 2018 21:28:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1726, Yet, IIUC, iiuc X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Nov 2018 21:28:27 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3D6D2307D986; Wed, 7 Nov 2018 21:28:26 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-54.rdu2.redhat.com [10.10.112.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id B55C318EEE; Wed, 7 Nov 2018 21:28:24 +0000 (UTC) Subject: Re: [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028) To: Martin Sebor , Richard Biener Cc: GCC Patches 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> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <072d934c-8bce-86d2-a842-562b40d6fda6@redhat.com> Date: Wed, 07 Nov 2018 21:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00487.txt.bz2 On 10/20/18 6:01 PM, Martin Sebor wrote: > > The warning only triggers when the bound is less than or equal > to the length of the constant source string (i.e, when strncpy > truncates).  So IIUC, your suggestion would defer folding only > such strncpy calls and let gimple_fold_builtin_strncpy fold > those with a constant bound that's greater than the length of > the constant source string.  That would be fine with me, but > since strncpy calls with a bound that's greater than the length > of the source are pointless I don't think they are important > enough to worry about folding super early.  The constant ones > that serve any purpose (and that are presumably important to > optimize) are those that truncate. I was focused exclusively on the case where we have to look for a subsequent statement that handled termination. The idea was to only leave in the cases that we might need to warn for because we couldn't search subsequent statement for the termination. Splitting up was primarily meant to get the warning out of the folder with a minimal impact on code generation. But if the common case would result in deferral of folding, then I'd fully expect Richi to object. > > That said, when optimization isn't enabled, I don't think users > expect calls to library functions to be transformed to calls to > other  functions, or inlined.  Yet that's just what GCC does. > For example, besides triggering the warning, the following: I don't think we should drag this into the issue at hand. Though I do generally agree that folding this stuff into low level memory operations is not what most would expect at -O0. Jeff