From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13334 invoked by alias); 23 Nov 2013 00:41:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13321 invoked by uid 89); 23 Nov 2013 00:41:50 -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_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Nov 2013 00:41:49 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Vk1Hv-0000rA-49 from joseph_myers@mentor.com ; Fri, 22 Nov 2013 16:41:31 -0800 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Nov 2013 16:41:31 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.2.247.3; Sat, 23 Nov 2013 00:41:29 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1Vk1Hr-000459-TM; Sat, 23 Nov 2013 00:41:28 +0000 Date: Sat, 23 Nov 2013 00:41:00 -0000 From: "Joseph S. Myers" To: DJ Delorie CC: , Subject: Re: proposal to make SIZE_TYPE more flexible In-Reply-To: <201311222118.rAMLIxag003002@greed.delorie.com> Message-ID: References: <201310300422.r9U4M6Mx002568@greed.delorie.com> <201310301917.r9UJHxg7028662@greed.delorie.com> <201310302219.r9UMJg9e001309@greed.delorie.com> <201311140158.rAE1wCkg006136@greed.delorie.com> <201311152338.rAFNc9CJ007961@greed.delorie.com> <201311212241.rALMf15B028014@greed.delorie.com> <201311220828.rAM8Ss0q011135@greed.delorie.com> <201311221933.rAMJXDUt031382@greed.delorie.com> <201311222118.rAMLIxag003002@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-11/txt/msg00482.txt.bz2 On Fri, 22 Nov 2013, DJ Delorie wrote: > > Does the target with __int20 actually have __int128 (i.e. pass > > targetm.scalar_mode_supported_p (TImode))? But you should indeed be able > > to have an arbitrary number of such types. > > It doesn't support it, but it does *have* it. In that the compiler > correcly parses the __int128 keyword and knows to tell you it isn't > supported. So, it needs at least two keywords. Which implies "it > needs two..." in other places. Making __int20 and __int128 exactly similar indicates __int128 *not* being a keyword on targets not supporting it. > And it's reasonable to expect that *someone* will want int16, int32, > etc types once a general solution is in place. As previously noted, it's best only to define such types where (a) there is an integer mode passing targetm.scalar_mode_supported_p and (b) no standard C type matches, to avoid issues with whether __int32 is the same as int or not. > > (d) I don't think the standard C types are particularly relevant to your > > project. > > Should we be pulling the int128 support out of the integer_types[] > list and put it in the global_trees[] (or some table) list? Because > most of the int128 support is tied in with the standard C type > handling, not the target-specific handling. My guess is that the int128 support doesn't belong in any of the existing global arrays, but in some new arrays supporting whatever set of intN types the target has. That's just a guess; whether you follow or don't follow it, your analysis of the code needs to justify your choice. -- Joseph S. Myers joseph@codesourcery.com