From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7532 invoked by alias); 16 Nov 2012 12:22:03 -0000 Received: (qmail 7519 invoked by uid 22791); 16 Nov 2012 12:22:00 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,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; Fri, 16 Nov 2012 12:21:52 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAGCLpTP024707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2012 07:21:51 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAGCLnGg001714; Fri, 16 Nov 2012 07:21:50 -0500 Message-ID: <50A62FDD.5000603@redhat.com> Date: Fri, 16 Nov 2012 12:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Diego Novillo CC: gcc-patches@gcc.gnu.org Subject: Re: VEC re-write [patch 01/25] References: <20121115215319.AE4ACC0916@torture.tor.corp.google.com> <50A61414.8070908@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-11/txt/msg01373.txt.bz2 On 16-11-2012 12:13, Diego Novillo wrote: > On Fri, Nov 16, 2012 at 5:23 AM, Pedro Alves wrote: > >> Was this considered? > > Yup. I just did not implement it. Would be a good follow up, though. Ah, good to know. Thanks. For the archives, cause gcc-patches@ bounced my mail for not being subscribed with this address ("too many recipients") what I had sent was: On 15-11-2012 21:53, Diego Novillo wrote: > The only thing I could not do is create proper ctors and dtors for the > vec class. Since these vectors are stored in unions, we > have to keep them as PODs (C++03 does not allow non-PODs in unions). How many cases are there of vecs in unions vs not in unions? It would seem natural to me to extend the POD vec type with a class that just adds the ctors and dtors, and call that new type the "vec" that is used mostly everywhere. The base POD vec (suggest "struct vec_pod", and then "struct vec : vec_pod {}") would then only be used in unions, and then only the code that needs to worry about initializing/releasing the unions would need to care about this. Was this considered? -- Pedro Alves