From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111230 invoked by alias); 7 Feb 2018 20:43:29 -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 111214 invoked by uid 89); 7 Feb 2018 20:43:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_FAIL,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 20:43:27 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2A8BC87AD2 for ; Wed, 7 Feb 2018 20:43:15 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-22.ams2.redhat.com [10.36.117.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 541792166BAE for ; Wed, 7 Feb 2018 20:43:14 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w17KWaj1008398; Wed, 7 Feb 2018 21:32:37 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w17KWYZQ008378; Wed, 7 Feb 2018 21:32:34 +0100 Date: Wed, 07 Feb 2018 20:43:00 -0000 From: Jakub Jelinek To: Jason Merrill Cc: Marek Polacek , Richard Biener , GCC Patches , Nathan Sidwell , Richard Sandiford Subject: Re: C++ PATCH to fix ICE with vector expr folding (PR c++/83659) Message-ID: <20180207203234.GR5867@tucnak> Reply-To: Jakub Jelinek References: <20180125144557.GO2063@tucnak> <20180126232216.GF2063@tucnak> <20180207175447.GD2608@redhat.com> <20180207193631.GE2608@redhat.com> <20180207194848.GP5867@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00357.txt.bz2 On Wed, Feb 07, 2018 at 03:23:25PM -0500, Jason Merrill wrote: > On Wed, Feb 7, 2018 at 2:48 PM, Jakub Jelinek wrote: > > On Wed, Feb 07, 2018 at 08:36:31PM +0100, Marek Polacek wrote: > >> > > That was my first patch, but it was rejected: > >> > > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00271.html > >> > > >> > Then should we update fold_indirect_ref_1 to use the new code? Is > >> > there a reason for them to stay out of sync? > >> > >> One of the reasons is that middle end uses poly_uint64 type but the front ends > >> shouldn't use them. So some of these functions will unfortunately differ. > > > > Yeah. Part of the patch makes the two implementations slightly more > > similar, but I have e.g. no idea how to test for poly_uint64 that fits > > also in poly_int64 and the poly_int* stuff makes the two substantially > > different in any case. > > Hmm. Well, that seems rather unfortunate. Why shouldn't the front > ends use them? Can we make an exception for this function because > it's supposed to mirror a middle-end function? > Should we try to push this function back into the middle end? The function comment seems to explain the reasons: /* A less strict version of fold_indirect_ref_1, which requires cv-quals to match. We want to be less strict for simple *& folding; if we have a non-const temporary that we access through a const pointer, that should work. We handle this here rather than change fold_indirect_ref_1 because we're dealing with things like ADDR_EXPR of INTEGER_CST which don't really make sense outside of constant expression evaluation. Also we want to allow folding to COMPONENT_REF, which could cause trouble with TBAA in fold_indirect_ref_1. Try to keep this function synced with fold_indirect_ref_1. */ E.g. the constexpr function uses same_type_ignoring_top_level_qualifiers_p instead of == type comparisons, the COMPONENT_REF stuff, ... For poly_* stuff, I think Richard S. wants to introduce it into the FEs at some point, but I could be wrong; certainly it hasn't been done yet and generally, poly*int seems to be a nightmare to deal with. Jakub