From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 9BF9A383542B for ; Fri, 7 May 2021 09:49:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9BF9A383542B Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-248-DSyg1D3NNTC9lTwFM8tf4A-1; Fri, 07 May 2021 05:49:56 -0400 X-MC-Unique: DSyg1D3NNTC9lTwFM8tf4A-1 Received: by mail-wr1-f72.google.com with SMTP id t18-20020adfdc120000b02900ffe4432d8bso3370747wri.6 for ; Fri, 07 May 2021 02:49:56 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5Eul+Ys+1DF2LeWa8JXldlfPDH5ZNnFv+1Vqd1VpAZg=; b=BPvwGRAAaqje0xeTOmbVjSPBxUnCs4Rc87jkcICIKZOCFcUdAVWzqYskEXCq1ukDTj IcEuxGE958LdzBfgL8v2oCBw1shzvlTIrZrZR/ZOWmyzZCtdPR+PDyLMSHSa5QHq+7HB wnMPsyxYQUnv/4OTYE0Rw6ahLBgfbQR50gUlmH9dA2BvUo7NvTisUxNrNDXoiDRnTGIN aXURxP5aCes4HRClIuHYQI/i3pNZOfCx0uD3lJSvFXCSrcNatnUqVg/Dj7jaB8aGCaGq 16HVtuJYOKdIRCg2SFw78B5YlEUMDZfO7Qjk6PVZGIPqmG2dJwNn+O0JXR0BFGvXysuB alfA== X-Gm-Message-State: AOAM5321Y3y8XPkBsDp3pI6VRbJfRpjUanUZsNzLOBxIxfEGpNJy2bQ7 D2X2zUyKpgpemZeaLFLjeEuuABDkqVQgfW3vfjcB4CXHI1/2EAUqr6AWERTjRSQsoStaEMkF4dd JG/CS3yLfEvYrUK1jmQ== X-Received: by 2002:adf:f2ce:: with SMTP id d14mr5867420wrp.384.1620380995484; Fri, 07 May 2021 02:49:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywilEEU6g7inyyLOSax1T/Ouq2MY2Pa/8mbW3btipUDjxdmchGu/pqsAsVM1nYl4UxZHdJjw== X-Received: by 2002:adf:f2ce:: with SMTP id d14mr5867390wrp.384.1620380995225; Fri, 07 May 2021 02:49:55 -0700 (PDT) Received: from abulafia.quesejoda.com ([95.169.237.215]) by smtp.gmail.com with ESMTPSA id k10sm26786886wmf.0.2021.05.07.02.49.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 May 2021 02:49:54 -0700 (PDT) Subject: Re: [PATCH] run early sprintf warning after SSA (PR 100325) To: Richard Biener , Martin Sebor Cc: gcc-patches , Andrew MacLeod References: From: Aldy Hernandez Message-ID: Date: Fri, 7 May 2021 11:49:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 09:50:00 -0000 On 5/7/21 11:34 AM, Richard Biener wrote: > On Fri, May 7, 2021 at 2:12 AM Martin Sebor wrote: >> >> On 5/6/21 8:32 AM, Aldy Hernandez wrote: >>> >>> >>> On 5/5/21 9:26 AM, Richard Biener wrote: >>>> On Wed, May 5, 2021 at 1:32 AM Martin Sebor via Gcc-patches >>>> wrote: >>>>> >>>>> With no optimization, -Wformat-overflow and -Wformat-truncation >>>>> runs early to detect a subset of simple bugs. But as it turns out, >>>>> the pass runs just a tad too early, before SSA. That causes it to >>>>> miss a class of problems that can easily be detected once code is >>>>> in SSA form, and I would expect might also cause false positives. >>>>> >>>>> The attached change moves the sprintf pass just after pass_build_ssa, >>>>> similar to other early flow-sensitive warnings (-Wnonnull-compare and >>>>> -Wuninitialized). >>>> >>>> Makes sense. I suppose walloca might also benefit from SSA - it seems >>>> to do range queries which won't work quite well w/o SSA? >>> >>> The early Walloca pass that runs without optimization doesn't do much, >>> as we've never had ranges so early. All it does is diagnose _every_ >>> call to alloca(), if -Walloca is passed: >>> >>> // The first time this pass is called, it is called before >>> // optimizations have been run and range information is unavailable, >>> // so we can only perform strict alloca checking. >>> if (first_time_p) >>> return warn_alloca != 0; >>> >>> Though, I suppose we could move the first alloca pass after SSA is >>> available and make it the one and only pass, since ranger only needs >>> SSA. However, I don't know how well this would work without value >>> numbering or CSE. For example, for gcc.dg/Walloca-4.c the gimple is: >>> >>> : >>> _1 = rear_ptr_9(D) - w_10(D); >>> _2 = (long unsigned int) _1; >>> if (_2 <= 4095) >>> goto ; [INV] >>> else >>> goto ; [INV] >>> >>> : >>> _3 = rear_ptr_9(D) - w_10(D); >>> _4 = (long unsigned int) _3; >>> src_16 = __builtin_alloca (_4); >>> goto ; [INV] >>> >>> No ranges can be determined for _4. However, if either FRE or DOM run, >>> as they do value numbering and CSE respectively, we could easily >>> determine a range as the above would become: >>> >>> : >>> _1 = rear_ptr_9(D) - w_10(D); >>> _2 = (long unsigned int) _1; >>> if (_2 <= 4095) >>> goto ; [INV] >>> else >>> goto ; [INV] >>> >>> : >>> src_16 = __builtin_alloca (_2); >>> goto ; [INV] >>> >>> I'm inclined to leave the first alloca pass before SSA runs, as it >>> doesn't do anything with ranges. If anyone's open to a simple -O0 CSE >>> type pass, it would be a different story. Thoughts? >> >> Improving the analysis at -O0 and getting better warnings that are >> more consistent with what is issued with optimization would be very >> helpful (as as long as it doesn't compromise debugging experience >> of course). > > I agree. It shouldn't be too difficult to for example run the VN > propagation part without doing actual elimiation and keep > value-numbers for consumption. do_rpo_vn (not exported) > might even already support iterate = false, eliminate = false, > it would just need factoring out the init/deinit somewhat. Interesting. This could give good ranges at -O0 and make it possible to move all these pesky range needy passes early in the pipeline. > Of course it will be a lot more expensive to do since it cannot > do "on-demand" value-numbering of interesting SSA names. > I'm not sure that would be possible anyhow. Though for > the alloca case quickly scanning the function whether there's > any would of course be faster than throwing VN at it. That's exact what we do for strict -Walloca warnings. For -Walloca-larger-than=, you need ranges though, so your VN idea would fit the bill. Aldy