From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18938 invoked by alias); 16 Oct 2014 05:48:39 -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 18928 invoked by uid 89); 16 Oct 2014 05:48:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_MXURI,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mail.ud10.udmedia.de Received: from ud10.udmedia.de (HELO mail.ud10.udmedia.de) (194.117.254.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 16 Oct 2014 05:48:36 +0000 Received: (qmail 15334 invoked from network); 16 Oct 2014 07:48:32 +0200 Received: from unknown (HELO x4) (ud10?360p3@91.64.94.144) by mail.ud10.udmedia.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Oct 2014 07:48:32 +0200 Date: Thu, 16 Oct 2014 06:25:00 -0000 From: Markus Trippelsdorf To: DJ Delorie Cc: joseph@codesourcery.com, gcc-patches@gcc.gnu.org, David Edelsohn , Aldy Hernandez , Michael Meissner Subject: Re: __intN patch 3/5: main __int128 -> __intN conversion. Message-ID: <20141016054832.GA339@x4> References: <201408220515.s7M5Fhpa007479@greed.delorie.com> <201408221924.s7MJOcjB022631@greed.delorie.com> <201408260303.s7Q33nqm024601@greed.delorie.com> <20141014201711.GA344@x4> <201410142110.s9ELAW4b019458@greed.delorie.com> <20141015081401.GA339@x4> <201410152100.s9FL0wvR009992@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201410152100.s9FL0wvR009992@greed.delorie.com> X-SW-Source: 2014-10/txt/msg01458.txt.bz2 On 2014.10.15 at 17:00 -0400, DJ Delorie wrote: > > > If you could implement the second option, it would be appreciated. > > Could you please test this for me? It builds as a powerpc-elf > cross-compiler (at least the host half) but I don't have a power > machine here to test on. > > Index: rs6000-c.c > =================================================================== > --- rs6000-c.c (revision 216241) > +++ rs6000-c.c (working copy) > @@ -157,12 +157,29 @@ init_vector_keywords (void) > { > __int128_type = get_identifier ("__int128_t"); > __uint128_type = get_identifier ("__uint128_t"); > } > } > > +/* Helper function to find out which RID_INT_N_* code is the one for > + __int128, if any. Returns RID_MAX+1 if none apply, which is safe > + (for our purposes, since we always expect to have __int128) to > + compare against. */ > +static int > +rid_int128(void) > +{ > + int i; > + > + for (i = 0; i < NUM_INT_N_ENTS; i ++) > + if (int_n_enabled_p[i] > + && int_n_data[i].bitsize == 128) > + return RID_INT_N_0 + i; > + > + return RID_MAX + 1; > +} > + > /* Called to decide whether a conditional macro should be expanded. > Since we have exactly one such macro (i.e, 'vector'), we do not > need to examine the 'tok' parameter. */ > > static cpp_hashnode * > rs6000_macro_to_expand (cpp_reader *pfile, const cpp_token *tok) > @@ -231,13 +248,13 @@ rs6000_macro_to_expand (cpp_reader *pfil > > if (rid_code == RID_UNSIGNED || rid_code == RID_LONG > || rid_code == RID_SHORT || rid_code == RID_SIGNED > || rid_code == RID_INT || rid_code == RID_CHAR > || rid_code == RID_FLOAT > || (rid_code == RID_DOUBLE && TARGET_VSX) > - || (rid_code == RID_INT128 && TARGET_VADDUQM)) > + || (rid_code == rid_int128 () && TARGET_VADDUQM)) > { > expand_this = C_CPP_HASHNODE (__vector_keyword); > /* If the next keyword is bool or pixel, it > will need to be expanded as well. */ > do > tok = cpp_peek_token (pfile, idx++); > Testing went fine (although there is a lot of noise because of the -std=gnu11 standard change). But I cannot approve the patch. Adding more people to CC. Thanks. -- Markus