From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35959 invoked by alias); 3 Aug 2015 15:39:31 -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 35941 invoked by uid 89); 3 Aug 2015 15:39:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 03 Aug 2015 15:39:30 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 1DEDE91EAB; Mon, 3 Aug 2015 15:39:29 +0000 (UTC) Received: from [10.10.116.17] ([10.10.116.17]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t73FdShe017460; Mon, 3 Aug 2015 11:39:28 -0400 Subject: Re: C++ delayed folding branch review To: Kai Tietz References: <557A5214.7060106@redhat.com> <55B911DD.30105@redhat.com> <55BA5667.9040200@redhat.com> <55BAACF9.7040707@redhat.com> <597173047.4338388.1438379666336.JavaMail.zimbra@redhat.com> <55BEE4CE.9070706@redhat.com> Cc: Kai Tietz , gcc-patches List From: Jason Merrill Message-ID: <55BF8B2B.9040001@redhat.com> Date: Mon, 03 Aug 2015 15:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg00088.txt.bz2 On 08/03/2015 05:42 AM, Kai Tietz wrote: > 2015-08-03 5:49 GMT+02:00 Jason Merrill : >> On 07/31/2015 05:54 PM, Kai Tietz wrote: >>> >>> The "STRIP_NOPS-requirement in 'reduced_constant_expression_p'" I could >>> remove, but for one case in constexpr. Without folding we don't do >>> type-sinking/raising. >> >> >> Right. >> >>> So binary/unary operations might be containing cast, which were in the >>> past unexpected. >> >> Why aren't the casts folded away? > > On such cast constructs, as for this vector-sample, we can't fold away Which testcase is this? > the cast chain. The difference here to none-delayed-folding branch is > that the cast isn't moved out of the plus-expr. What we see now is > (plus ((vec) (const vector ...) { .... }), ...). Before we had (vec) > (plus (const vector ...) { ... }). How could a PLUS_EXPR be considered a reduced constant, regardless of where the cast is? >>> On verify_constant we check by reduced_constant_expression_p, if value is >>> a constant. We don't handle here, that NOP_EXPRs are something we want to >>> look through here, as it doesn't change anything if this is a constant, or >>> not. >> >> NOPs around constants should have been folded away by the time we get there. > > Not in this cases, as the we actually have here a switch from const to > none-const. So there is an attribute-change, which we can't ignore in > general. I wasn't suggesting we ignore it, we should be able to change the type of the vector_cst. > But I agree that for constexpr's we could special case cast > from const to none-const (as required in expressions like const vec v > = v + 1). Right. But really this should happen in convert.c, it shouldn't be specific to C++. Jason