From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20421 invoked by alias); 3 Jan 2018 17:45:49 -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 20412 invoked by uid 89); 3 Jan 2018 17:45:48 -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,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*i:sk:87a7xuk, H*f:sk:87a7xuk 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, 03 Jan 2018 17:45:47 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BD0B780461; Wed, 3 Jan 2018 17:45:46 +0000 (UTC) Received: from redhat.com (ovpn-204-27.brq.redhat.com [10.40.204.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9713560C9E; Wed, 3 Jan 2018 17:45:45 +0000 (UTC) Date: Wed, 03 Jan 2018 17:45:00 -0000 From: Marek Polacek To: GCC Patches , Jason Merrill , Nathan Sidwell , richard.sandiford@linaro.org Subject: Re: C++ PATCH to fix ICE with vector expr folding (PR c++/83659) Message-ID: <20180103174541.GH23422@redhat.com> References: <20180103163107.GF23422@redhat.com> <87a7xukfhr.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a7xukfhr.fsf@linaro.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-SW-Source: 2018-01/txt/msg00161.txt.bz2 On Wed, Jan 03, 2018 at 05:40:32PM +0000, Richard Sandiford wrote: > Marek Polacek writes: > > Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR > > with offset > signed HOST_WIDE_INT and we tried to convert it to sHWI. > > > > The matching code in fold_indirect_ref_1 uses uHWIs so I've followed suit. > > But that code now also uses poly_uint64 and I'm not sure if any of the > > constexpr.c code should use it, too. > > The frontend isn't supposed to see any poly_ints (yet), so it's OK to > keep on using INTEGER_CST accessors like tree_to_shwi and tree_to_uhwi. Thanks, that's good to know. Marek