From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17246 invoked by alias); 27 Jun 2013 16:10:14 -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 17216 invoked by uid 89); 27 Jun 2013 16:10:10 -0000 X-Spam-SWARE-Status: No, score=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 27 Jun 2013 16:10:09 +0000 Received: from stedding.saclay.inria.fr ([193.55.250.194]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 27 Jun 2013 18:10:03 +0200 Received: from glisse (helo=localhost) by stedding.saclay.inria.fr with local-esmtp (Exim 4.80) (envelope-from ) id 1UsEln-0006YN-3k; Thu, 27 Jun 2013 18:10:03 +0200 Date: Thu, 27 Jun 2013 16:10:00 -0000 From: Marc Glisse To: Jakub Jelinek cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [C++] Fix __builtin_shuffle In-Reply-To: <20130627160057.GF2336@tucnak.redhat.com> Message-ID: References: <51CB558B.6090905@redhat.com> <51CC2F9D.908@redhat.com> <20130627153313.GE2336@tucnak.redhat.com> <20130627160057.GF2336@tucnak.redhat.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SW-Source: 2013-06/txt/msg01537.txt.bz2 On Thu, 27 Jun 2013, Jakub Jelinek wrote: > On Thu, Jun 27, 2013 at 05:54:10PM +0200, Marc Glisse wrote: >> I don't really see why, as I am still calling c_build_vec_perm_expr >> in the same cases, just possibly not exactly with the same arguments >> (they don't go through build_non_dependent_expr, but Jason seemed to >> imply that it did not matter since we don't look too deep through >> the arguments). > > I guess you're right. If the c_* routine doesn't mind C++ specific trees > and just cares about their types and pt.c then instantiates it, then it is > fine. Even if both are fine, if you prefer the long version (safer, or more uniform with the rest), please say so, I don't mind. -- Marc Glisse