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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id B967B3AAA084 for ; Thu, 6 May 2021 14:32:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B967B3AAA084 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-199-8XnnuwXJNAS6TUF1JSVN-Q-1; Thu, 06 May 2021 10:32:31 -0400 X-MC-Unique: 8XnnuwXJNAS6TUF1JSVN-Q-1 Received: by mail-wr1-f70.google.com with SMTP id l2-20020adf9f020000b029010d6bb7f1cbso2273350wrf.7 for ; Thu, 06 May 2021 07:32:31 -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=vMUUAKWOX8hPTWWGtEdSp/yXlcm4NvywsD+gH9ZRydc=; b=ByVilgYWYcKHfL/L6n+BqsF80B7uLF8j9tVy+67zkYSwEkJDPJ5AQ7HDeNMTX6Ojde 3LJBznuMXd3iBnV5QhH1oP7HkeoYMKhz4Y4yLsMBpyV267QJc7BrAzwSz3j7ekZuvwb8 qAhvdTDFsPLA6kE9OTUSTJlNXeGH+KyM9Yq8i04QhyFvoVNiiDjjFmkdoqoBrPT19pi8 ZTU+/YGu7sG7OvF5MriEDXNRxGSQA8sv5ZIZfaSZt0zM10MEqvW/empEFXHF3JZT/8CU +JMvAsfjBwm29xp7JlkS0cLpC8Ztr82J7k6TBjyMWXgqptZM8n4ovonbbQl68LiA2yv2 afUQ== X-Gm-Message-State: AOAM530gOm+v96RnJEFmQ0tjRS1KcPiWUhabBaNtAKUNpUy1L2w295fa Zxr4WLUbzYtGmKljvHL+r1ymUf7uBE7VLq7Quya1Xv41bR3XyNtxG+Cp6684wsMwltR22oEyCRq mqKimB5OGZ6LFwUaF1w== X-Received: by 2002:a1c:4d01:: with SMTP id o1mr4431693wmh.42.1620311550091; Thu, 06 May 2021 07:32:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/c1U5K/KlhE+mp+2enP78LsJIKmMRgKopty7GpuoYjtb1tl/cRxw9osGmOy9pKmJBPtRUbQ== X-Received: by 2002:a1c:4d01:: with SMTP id o1mr4431658wmh.42.1620311549852; Thu, 06 May 2021 07:32:29 -0700 (PDT) Received: from abulafia.quesejoda.com ([95.169.237.215]) by smtp.gmail.com with ESMTPSA id y5sm4363396wrm.61.2021.05.06.07.32.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 May 2021 07:32:29 -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: Thu, 6 May 2021 16:32:28 +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: Thu, 06 May 2021 14:32:35 -0000 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? Aldy