From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26204 invoked by alias); 13 Feb 2020 17:42:40 -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 26193 invoked by uid 89); 13 Feb 2020 17:42:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-qv1-f67.google.com Received: from mail-qv1-f67.google.com (HELO mail-qv1-f67.google.com) (209.85.219.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 17:42:38 +0000 Received: by mail-qv1-f67.google.com with SMTP id dc14so2990668qvb.9 for ; Thu, 13 Feb 2020 09:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dp59s1QnMtZtXmmN/jigSY60OCU0Es8QZnk2+b48ro4=; b=PCPH9OM3rWz+r5mFCxBCwRfkndJHIBb6/7A1XJ2gshoc9FdT5NpnEQ3kJ2ff3Sbbbv hfJ6DDKdpFiGAWgixsejYY5NeSRMgY9RuOblBIykPoLxpyWt0hMAsNmPMo3dh788Mvxv 8jW7GJbwPeO3ytKW/IKrQNZ/X1rZuu0aV2PkgV5wwanDS8XtZ16IwUtYJw+dpIX0mCyF oAL0ozaOJZvHcI5+UE/B4bAaVjJe6Tw4HHYTHGfJUw7tEfYi+sLVpmzk7WIqbUS45E/3 +s6W0M2jw+wQdH0aKB4LWELdeDKs6CqGW6U30ci09SlMMTjm3oJRfS9X7sBS/pdaY4yn I+lg== Return-Path: Received: from [192.168.0.41] (174-16-112-158.hlrn.qwest.net. [174.16.112.158]) by smtp.gmail.com with ESMTPSA id w21sm1993470qth.17.2020.02.13.09.42.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Feb 2020 09:42:35 -0800 (PST) Subject: Re: Patch ping To: Jakub Jelinek , Jeff Law Cc: Jason Merrill , Richard Earnshaw , Ramana Radhakrishnan , Kyrylo Tkachov , gcc-patches@gcc.gnu.org References: <20200210092415.GJ17695@tucnak> <241d00a5cabb62b38c6c1f83917510527a097353.camel@redhat.com> <20200213095419.GH17695@tucnak> From: Martin Sebor Message-ID: Date: Thu, 13 Feb 2020 17:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20200213095419.GH17695@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00799.txt.bz2 On 2/13/20 2:54 AM, Jakub Jelinek wrote: > On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote: >> On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote: >>> Hi! >>> >>> I'd like to ping a couple of patches: >>> >>> PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix >>> https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00010.html >> Letting the ARM guys deal with this. > > Yes, that is resolved now (Richard E. committed his patch and I've > committed the testcase). > >>> PR preprocessor/92319 - partially implement P1042R1: __VA_OPT__ wording clarifications >>> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02104.html >> Jason for this one. > > Of course; I just chose to send a ping for all my pending patches and > add to To: all relevant maintainers. > >>> PR target/93069 - avx512* rejects-valid fix (rejected by assembler) >>> http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01606.html >> This is in my queue :-) > > Ok. > >>> PR tree-optimization/92868 - compute_objsize/gimple_call_alloc_size >>> /maybe_warn_overflow fixes >>> http://gcc.gnu.org/ml/gcc-patches/2019-12/msg01164.html >> Martin's patch should have addressed all the issues and should include >> your tests (tweaked, but supposed to be equivalent). > > No, this is something different, this isn't what has been covered by the > testcases, but something found by code inspection, mainly inconsistencies > in the APIs, e.g. the ranges represented as sizetype most of the time, > but with one exception where it could be some other type (wider or > narrower), or sometimes the range being incorrect (if there is possible > overflow and we punt, we didn't change the ranges effectively to VARYING, > but just capped the maximum), or INTEGER_CSTs compared by pointer equality > rather than operand_equal_p. As I said repeatedly in my comments on the patch, I'm not in favor of these changes. I don't think they hurt anything but they also don't fix anything that I can see. There's is no bug the change fixes (PR 92868 is closed as resolved) or a test case included in the patch that verifies the improvement. The changes are also not in the direction I'd like to see this code evolve. Martin