From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114455 invoked by alias); 23 Nov 2015 10:12:13 -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 114439 invoked by uid 89); 23 Nov 2015 10:12:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f171.google.com Received: from mail-yk0-f171.google.com (HELO mail-yk0-f171.google.com) (209.85.160.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 23 Nov 2015 10:12:08 +0000 Received: by ykfs79 with SMTP id s79so232830132ykf.1 for ; Mon, 23 Nov 2015 02:12:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.148.65 with SMTP id l62mr25206925ywg.263.1448273526231; Mon, 23 Nov 2015 02:12:06 -0800 (PST) Received: by 10.37.93.11 with HTTP; Mon, 23 Nov 2015 02:12:06 -0800 (PST) In-Reply-To: References: <564F7B57.4060703@redhat.com> Date: Mon, 23 Nov 2015 10:17:00 -0000 Message-ID: Subject: Re: RFA: PATCH to match.pd for c++/68385 From: Richard Biener To: GCC Patches Cc: Jason Merrill , Ramana Radhakrishnan Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02671.txt.bz2 On Sat, Nov 21, 2015 at 7:57 PM, Marc Glisse wrote: > On Sat, 21 Nov 2015, Richard Biener wrote: > >> On November 20, 2015 8:58:15 PM GMT+01:00, Jason Merrill >> 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? > > > I had the same reaction. > >> Do other integer predicates strip nops? > > > Yes, they do. > > I believe I added one or two of those, and the reason I added STRIP_NOPS is > because they started as a copy-paste of integer_zerop... Ok... Jason, from looking at the PRs backtrace I see the C++ FE does things like if (complain & tf_warning) warn_logical_operator (loc, code, boolean_type_node, code_orig_arg1, fold (arg1), code_orig_arg2, fold (arg2)); but that's in principle a no-no, if arg1s operands are not folded. Delayed folding needs to happen recursively, bottom-up. Folders generally do not expect unfolded operands like (int) 1. There is c-common.c:c_fully_fold () which does this properly but with /* This function is not relevant to C++ because C++ folds while parsing, and may need changes to be correct for C++ when C++ stops folding while parsing. */ if (c_dialect_cxx ()) gcc_unreachable (); not sure if the C++ FE can re-use this for the diagnostic cases. Richard. > -- > Marc Glisse