From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108650 invoked by alias); 20 Feb 2018 18:48:50 -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 108601 invoked by uid 89); 20 Feb 2018 18:48:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=HContent-Transfer-Encoding:8bit 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; Tue, 20 Feb 2018 18:48:47 +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 556F483F3E for ; Tue, 20 Feb 2018 18:48:45 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-67.rdu2.redhat.com [10.10.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id C64725C579 for ; Tue, 20 Feb 2018 18:48:44 +0000 (UTC) From: Jeff Law Subject: [PR middle-end/82123] 00/06 Use EVRP range data in sprintf warnings To: gcc-patches Message-ID: Date: Tue, 20 Feb 2018 18:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg01180.txt.bz2 So I'm finally getting back to this. To recap, the issue here is the sprintf pass is querying global range information. As a result the range for the key object is not narrowed by the conditionals leading to the sprintf call and we get a false positive (pr81592 and pr82123). The plan for the last few months was to use the embeddable range analyzer to get the narrowed range. I'd dropped in a bit of infrastructure to do that a while back, but got side tracked by spectre and meltdown before I could push it to completion. This patch completes the work. It ties the range analyzer into the dominator walk (which was trivial) and arranges to query the range analyzer rather than the global data. The patch is bigger than one might expect primarily because the points where we want to issue the queries are in free functions rather than in member functions. Rather than go through a round of refactoring to bring those free functions into the class hierarchy, I just passed around the range data. It's the same trivial change in a bunch of places to pass vr_values down. So it looks big, but is dead simple in reality. We query the data in 3 places in the fairly obvious way. My initial patch actually created a get_range_info member function within vr_values that had the same signature as the free function get_range_info in tree-ssanames.c That works, but ultimately I decided it was more confusing than using the existing get_value_range member function. So this version uses the existing get_value_range member function. The fix is broken into a half-dozen patches in my local tree. I didn't see any value in squashing them together -- so I'm posting them as a 6 series kit, even though they're pretty simple. Bootstrapped and regression tested on x86_64-linux-gnu. Verified it fixes both 81592 and 82123. Jeff