From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78157 invoked by alias); 3 May 2017 14:46:59 -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 78127 invoked by uid 89); 3 May 2017 14:46:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:209.85.216.194, Hx-spam-relays-external:209.85.216.194, H*f:sk:2uFcA@m, H*i:sk:2uFcA@m X-HELO: mail-qt0-f194.google.com Received: from mail-qt0-f194.google.com (HELO mail-qt0-f194.google.com) (209.85.216.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 May 2017 14:46:56 +0000 Received: by mail-qt0-f194.google.com with SMTP id o36so24934001qtb.2 for ; Wed, 03 May 2017 07:46:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=j1Kn50xz6Eh1NdLpOIP7BlvTlPsyVKb8kjJ2javZ/Z4=; b=G/aJYkOj4nK7LOJMxhDKXjWVrjP7vAGj2Xp63YAh11SGJ/XwwNoScp3+OSXkbKIuPo 90EtaUOc9uHsNye7Bn4zbDjo0NACldNl398yQ8OJ9CmlRnHT4/E3SNPyDCZfHM92aYHC ZGrKlMJlgbaZ0uqt3qFOTaqb5ESQl/1C0/kiBEztZXsHfb4a3fH0c4c94crSSyNkih96 ZO1NIk94cv0sP8YyrmOaj2SWheaHicq/Zmq56s9r26BPbD9iCxc4hZz0SKeR/PGr2qfY tJ03HBmqhfwouUii4uOzACsKwhzSExte83HXSQ3DnikX2ec+k11JNJmNGBz6U+1sMFEa hGEQ== X-Gm-Message-State: AN3rC/4AmVKKpPnnQwOWL4BjUECA9mTPl2zsQ3N+FmenEduMJhcsq3yL UwJlKUiLtBjizA== X-Received: by 10.200.42.238 with SMTP id c43mr32871442qta.144.1493822817301; Wed, 03 May 2017 07:46:57 -0700 (PDT) Received: from localhost.localdomain (75-166-101-229.hlrn.qwest.net. [75.166.101.229]) by smtp.gmail.com with ESMTPSA id c142sm1648437qkb.10.2017.05.03.07.46.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 07:46:56 -0700 (PDT) Subject: Re: [PATCH] handle sprintf(d, "%s", ...) in gimple-ssa-sprintf.c To: Richard Biener , Jeff Law 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> Cc: Gcc Patch List From: Martin Sebor Message-ID: <59cdeacb-05ef-eb2b-0919-089aeecb0355@gmail.com> Date: Wed, 03 May 2017 14:48: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: 2017-05/txt/msg00213.txt.bz2 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)? Martin