From patchwork Thu Dec 6 07:16:40 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 204160 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 7BB492C0172 for ; Thu, 6 Dec 2012 18:16:59 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1355383020; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=8iF38zyuGsr5D8Urn3iQ OmEK6kU=; b=e8kmUPKR8yPFBD3SHGyVJXh4irVpA7kA0rGE+cR6/9iUU8N8CX5I +h+zXRGCAf0wJCzcfU17SKLnWB073Dn566wrTm6G2qcaGaL5DYHbSXXvsov2nLpw /p5s7dBKlu17vbL9s8KMmZY5QIEZbJ5CeOTxkk9GSoxqCMbQTvSGTaM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=s032IB/t/RbVsEcgpChDNhemIUF7wzoSelzW9r3h/F2avFw0//+SY65Pilqj3H YeZ9aTj1S7O3RrB8mkrKwndA//JBt1iOKXq1uPXVw485l5arFJcCwM7LRizW4bJv javcUG2ciZf8bTcSu3d7yRAHRABOO9nzEUW6zHn4cEKXk=; Received: (qmail 11074 invoked by alias); 6 Dec 2012 07:16:55 -0000 Received: (qmail 11066 invoked by uid 22791); 6 Dec 2012 07:16:53 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Dec 2012 07:16:44 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB67Ghhi031301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Dec 2012 02:16:44 -0500 Received: from zalov.redhat.com (vpn1-6-17.ams2.redhat.com [10.36.6.17]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qB67Gf3N012825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2012 02:16:43 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qB67Gf9D012913; Thu, 6 Dec 2012 08:16:41 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qB67GeWZ012912; Thu, 6 Dec 2012 08:16:40 +0100 Date: Thu, 6 Dec 2012 08:16:40 +0100 From: Jakub Jelinek To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: [C++ PATCH] Handle VECTOR_CSTs in adjust_temp_type (PR c++/55573) Message-ID: <20121206071640.GF2315@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! With Marc's recent changes to fold vector CONSTRUCTORs into VECTOR_CSTs if possible, we now ICE in adjust_temp_type, because the type of VECTOR_CST is not SCALAR_TYPE_P. Either we can handle VECTOR_CSTs directly (in that case ignore_overflows is also called on each VECTOR_CST constant, but not sure if that is needed), as done in the patch below, or Marc has an alternative patch to just change the assert into gcc_assert (scalarish_type_p); Which way do you prefer? This one has been bootstrapped/regtested on x86_64-linux and i686-linux. BTW, the PR and the referenced PR contains some other patches, e.g. cp_tree_equal not handling VECTOR_CSTs. For that it is a similar question, either VECTOR_CSTs can be handled there using operand_equal_p, or by calling cp_tree_equal on the VECTOR_CST elements. 2012-12-06 Jakub Jelinek PR c++/55573 * semantics.c (adjust_temp_type): Handle VECTOR_CST. * g++.dg/cpp0x/constexpr-55573.C: New test. Jakub --- gcc/cp/semantics.c.jj 2012-11-23 00:14:40.000000000 +0100 +++ gcc/cp/semantics.c 2012-12-03 14:02:54.407690163 +0100 @@ -6451,6 +6451,14 @@ adjust_temp_type (tree type, tree temp) /* Avoid wrapping an aggregate value in a NOP_EXPR. */ if (TREE_CODE (temp) == CONSTRUCTOR) return build_constructor (type, CONSTRUCTOR_ELTS (temp)); + if (TREE_CODE (temp) == VECTOR_CST) + { + int i, count = TYPE_VECTOR_SUBPARTS (type); + tree *vec = XALLOCAVEC (tree, count); + for (i = 0; i < count; i++) + vec[i] = cp_fold_convert (TREE_TYPE (type), VECTOR_CST_ELT (temp, i)); + return build_vector (type, vec); + } gcc_assert (SCALAR_TYPE_P (type)); return cp_fold_convert (type, temp); } --- gcc/testsuite/g++.dg/cpp0x/constexpr-55573.C.jj 2012-12-03 14:21:05.367303150 +0100 +++ gcc/testsuite/g++.dg/cpp0x/constexpr-55573.C 2012-12-03 14:19:42.000000000 +0100 @@ -0,0 +1,22 @@ +// PR c++/55573 +// { dg-do compile } +// { dg-options "-std=gnu++11" } + +template +struct ExtVecTraits { + typedef T __attribute__((vector_size (N * sizeof (T)))) type; +}; + +template +using Vec4 = typename ExtVecTraits::type; + +template +struct Rot3 +{ + typedef Vec4 Vec; + Vec axis[3]; + constexpr Rot3 (Vec4 ix, Vec4 iy, Vec4 iz) : axis {ix, iy, iz} {} +}; + +typedef Vec4 Vec; +Rot3 r2 ((Vec) {0, 1, 0, 0}, (Vec){0, 0, 1, 0}, (Vec){1, 0, 0, 0});