From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55745 invoked by alias); 12 May 2017 18:42:20 -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 55731 invoked by uid 89); 12 May 2017 18:42:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=deeply, suppressed 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; Fri, 12 May 2017 18:42:18 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EE3E83D956; Fri, 12 May 2017 18:42:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EE3E83D956 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com EE3E83D956 Received: from localhost.localdomain (ovpn-116-74.phx2.redhat.com [10.3.116.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id A928E5C890; Fri, 12 May 2017 18:42:19 +0000 (UTC) Subject: Re: [PATCH] handle sprintf(d, "%s", ...) in gimple-ssa-sprintf.c To: Martin Sebor , Richard Biener Cc: Gcc Patch List References: <64b29bd5-d59e-8268-5042-285912738ae4@gmail.com> <9e1a955c-6a93-3235-50ac-c00ba39d436f@gmail.com> <0de09846-2f84-4763-58b2-b31e5490a6bb@redhat.com> <960a2d6c-e64e-daab-6852-77b3d382ad39@gmail.com> <59cdeacb-05ef-eb2b-0919-089aeecb0355@gmail.com> From: Jeff Law Message-ID: <8e119099-f4aa-c677-0089-9fec54cbc74c@redhat.com> Date: Fri, 12 May 2017 18:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <59cdeacb-05ef-eb2b-0919-089aeecb0355@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg01065.txt.bz2 On 05/03/2017 08:46 AM, Martin Sebor wrote: > On 05/03/2017 04:20 AM, Richard Biener wrote: >> On Tue, May 2, 2017 at 4:41 PM, Martin Sebor wrote: >>>>>> FWIW, my fix for bug 79062 is only partial (it gets the pass >>>>>> to run but the warnings are still not issued). I don't quite >>>>>> understand what prevents the warning flag(s) from getting set >>>>>> when -flto is used. This seems to be a bigger problem than >>>>>> just the sprintf pass not doing something just right. >>>>> >>>>> >>>>> I've never dug deeply in the LTO stuff, but I believe we stream the >>>>> compiler >>>>> flags, so it could be something there. >>>> >>>> >>>> We do. >>>> >>>>> Alternately you might be running into a case where in LTO mode we >>>>> recreate >>>>> base types. Look for a type equality tester that goes beyond just >>>>> testing >>>>> pointer equality. >>>>> >>>>> ie, in LTO I think we'll create a type based on the streamed data, >>>>> but I >>>>> also think we'll create various basic types. Thus in LTO mode pointer >>>>> equality may not be sufficient. >>>> >>>> >>>> We make sure that for most basic types we end up re-using them where >>>> possible. >>>> char_type_node is an example where that generally doesn't work because >>>> it's >>>> value depends on a command-line flag. >>> >>> >>> That answers the first part of the question of why the sprintf >>> pass wouldn't run (or do anything) with -flto. With it fixed >>> (as in fold-const.c or tree-ssa-strlen.c as you suggested in >>> bug 79602) it runs and the optimization does its job, but no >>> warnings are issued. The wan_foo_flags for warnings that are >>> enabled implicitly (e.g., by -Wall or -Wextra on the command >>> line) are clear. There seem to be dependencies between warnings >>> in c.opt that ignore LTO (as a language), but even with those >>> corrected (i.e., with LTO added as a language to -Wformat and >>> -Wall) the flags are still clear when LTO runs. Does that ring >>> any bells for you? >> >> You can look at the lto_opts section (it's just a string) and see >> that we seem to fail to pass through -Wall (or any warning option >> I tried). This is because >> >> /* Also drop all options that are handled by the driver as well, >> which includes things like -o and -v or -fhelp for example. >> We do not need those. The only exception is -foffload >> option, if we >> write it in offload_lto section. Also drop all diagnostic >> options. */ >> if ((cl_options[option->opt_index].flags & (CL_DRIVER|CL_WARNING)) >> && (!lto_stream_offload_p || option->opt_index != >> OPT_foffload_)) >> continue; >> >> which means you have to explicitely enable diagnostics you want at >> link time at the moment. >> >> If you want to change that you have to do some changes to lto-wrapper.c >> as for example only pass through warning options that are set on all >> input files (warning options are not kept per function). > > Great, thanks for the pointer! I might tackle that at some point. > > Jeff, given that we now understand why the warnings are suppressed > (i.e., the root cause of the rest of bug 79062), are you okay with > treating that independently of this PR (bug 77671) and committing > this patch (including the two-line fix to enable the sprintf return > value optimization with LTO)? Yea. I think you needed to add a function comment for is_call_safe and try_simplify_call. With those additions this is OK. Sorry for the delay. jeff