From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93078 invoked by alias); 21 Feb 2018 03:25: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 93064 invoked by uid 89); 21 Feb 2018 03:25:20 -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= 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; Wed, 21 Feb 2018 03:25:19 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5E093C0587C7; Wed, 21 Feb 2018 03:25:17 +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 2D3E9608F1; Wed, 21 Feb 2018 03:25:15 +0000 (UTC) Subject: Re: [PATCH] Fix pdftex miscompilation due to get_range_strlen (PR tree-optimization/84478) To: Martin Sebor , Jakub Jelinek Cc: Richard Biener , gcc-patches@gcc.gnu.org References: <20180220171712.GH5867@tucnak> <20180220204948.GJ5867@tucnak> <6f9446cc-e61c-7f6b-1270-2b47546726f2@gmail.com> From: Jeff Law Message-ID: <5e9832c6-9131-4851-e920-afe923aa0ba7@redhat.com> Date: Wed, 21 Feb 2018 03:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6f9446cc-e61c-7f6b-1270-2b47546726f2@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg01209.txt.bz2 On 02/20/2018 04:59 PM, Martin Sebor wrote: >> It would help if you explained why you think it is a good idea >> ignoring the other phi arguments if you have one (or more) where you can >> determine length. > > It's a heuristic that was meant just for the -Wformat-overflow > warning.  When making decisions that affect code generation it's > obviously not correct to ignore the possibility that unknown > arguments may be shorter than the minimum or longer than > the maximum.  The fuzzy argument was meant to differentiate > between two got but I forgot about it when I added the fix > for PR 83671. > > For GCC 8 I don't have a preference for how to fix this as long > as it doesn't regress the warning tests. > > I think the ultimate solution (for GCC 9) may be to either > disable the heuristic for code generation purposes (e.g., via > another argument/flag) or provide a pointer argument to indicate > to the caller that the minimum is based on known strings, and that > the real minimum may be zero. I'm still getting refamiliar with this code. But one thing that jumps out immediately is how much this reminds me of the discussion we had around 77608 -- where I argued that returning something that was not conservatively correct was just asking for long term problems. I realize we're talking about different routines, but the concerns are the same -- when we return something that is not conservatively correct it's easy for someone to mistakenly use those results for code generation purposes. The fuzzy stuff is in there to reduce the false positive rates and we're not *supposed* to be using fuzzy results for code generation purposes, but as I argued in 77608, it's easy to miss. I'll reiterate my desire to make this kind of mistake harder to make. Jeff