From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-414846-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 82003 invoked by alias); 21 Nov 2015 06:30:24 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 81974 invoked by uid 89); 21 Nov 2015 06:30:23 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-wm0-f44.google.com
Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 21 Nov 2015 06:30:22 +0000
Received: by wmec201 with SMTP id c201so45862367wme.1        for <gcc-patches@gcc.gnu.org>; Fri, 20 Nov 2015 22:30:19 -0800 (PST)
X-Received: by 10.194.71.104 with SMTP id t8mr18105321wju.177.1448087419019;        Fri, 20 Nov 2015 22:30:19 -0800 (PST)
Received: from android-4c5a376a18c0e957.fritz.box (p4FE9C3E6.dip0.t-ipconnect.de. [79.233.195.230])        by smtp.gmail.com with ESMTPSA id w203sm2639901wmg.15.2015.11.20.22.30.18        (version=TLSv1/SSLv3 cipher=OTHER);        Fri, 20 Nov 2015 22:30:18 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <564F7B57.4060703@redhat.com>
References: <564F7B57.4060703@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Subject: Re: RFA: PATCH to match.pd for c++/68385
From: Richard Biener <richard.guenther@gmail.com>
Date: Sat, 21 Nov 2015 06:31:00 -0000
To: Jason Merrill <jason@redhat.com>
CC: gcc-patches List <gcc-patches@gcc.gnu.org>,Ramana Radhakrishnan <ramana.gcc@googlemail.com>
Message-ID: <F68952C0-4EAA-4D5E-900F-F51E5291858F@gmail.com>
X-IsSubscribed: yes
X-SW-Source: 2015-11/txt/msg02562.txt.bz2

On November 20, 2015 8:58:15 PM GMT+01:00, Jason Merrill <jason@redhat.com> wrote:
>In this bug, we hit the (A & sign-bit) != 0 -> A < 0 transformation. 
>Because of delayed folding, the operands aren't fully folded yet, so we
>
>have NOP_EXPRs around INTEGER_CSTs, and so calling wi::only_sign_bit_p 
>ICEs.  We've been seeing several similar bugs, where code calls 
>integer_zerop and therefore assumes that they have an INTEGER_CST, but 
>in fact integer_zerop does STRIP_NOPS.
>
>This patch changes the pattern to only match if the operand is actually
>
>an INTEGER_CST.  Alternatively we could call tree_strip_nop_conversions
>
>on the operand, but I would expect that to have issues when the 
>conversion changes the signedness of the type.
>
>OK if testing passes?

What happens if we remove the nops stripping from integer_zerop?  Do other integer predicates strip nops?

Richard.