From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11120 invoked by alias); 9 Jan 2014 02:31:17 -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 11097 invoked by uid 89); 9 Jan 2014 02:31:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Jan 2014 02:31:13 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1W15On-0005zw-Mg from joseph_myers@mentor.com ; Wed, 08 Jan 2014 18:31:09 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jan 2014 18:31:09 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 9 Jan 2014 02:31:07 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1W15Ok-0003HI-Iv; Thu, 09 Jan 2014 02:31:06 +0000 Date: Thu, 09 Jan 2014 03:23:00 -0000 From: "Joseph S. Myers" To: DJ Delorie CC: , Subject: Re: proposal to make SIZE_TYPE more flexible In-Reply-To: <201401090031.s090VGm9003938@greed.delorie.com> Message-ID: References: <201310300422.r9U4M6Mx002568@greed.delorie.com> <201311220828.rAM8Ss0q011135@greed.delorie.com> <201311221933.rAMJXDUt031382@greed.delorie.com> <201311222118.rAMLIxag003002@greed.delorie.com> <201312100334.rBA3YwMq017441@greed.delorie.com> <201312201947.rBKJlgKS003922@greed.delorie.com> <201312202159.rBKLxmIZ007173@greed.delorie.com> <201312202240.rBKMeVfM008400@greed.delorie.com> <201401090031.s090VGm9003938@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-01/txt/msg00061.txt.bz2 On Wed, 8 Jan 2014, DJ Delorie wrote: > > I think a patch is more useful once believe feature-complete, which > > means replacing the __int128 support with the new mechanism. > > One of the side-effects of taking out the existing __int128 support is > that __int128 isn't in the integer_type_kind list, so isn't a type > that is usable for constants. This breaks int128-4.C, which assumes a > 128-bit integer constant. If I add generic support for intN types in I don't see constants in that test. It's not possible to write constants of type __int128 anyway. It *is* possible to build them up using expressions casting narrower constants to __int128. If you write a constant with a large value (with or without a suffix) that won't fit in target intmax_t / uintmax_t (or target long / unsigned long for C90), then you should get a pedwarn (and some larger type, maybe widest_integer_literal_type_node / widest_unsigned_literal_type_node, will be used if available). > i_t_k[], then we'll get (for example) 20-bit constants, which might > not be what we want. The only other option is to special-case > __int128 if we find it in the __intN list. Integer constant types should be taken from the int / long / long long (and unsigned variants) list. If a constant can't fit in any type ISO C allows for it, then it's reasonable to go on the extended types wider than long long, in increasing order of size, but __int20 is never relevant for constants as it's always narrower than long. > Thoughts? It's desirable anyway to have a way of representing what might be a standard type from integer_type_kind, or an extended type, given that it would be good for macros such as SIZE_TYPE to evaluate to enumerated values not magic strings. Maybe a reserved space of itk_* values just like reserving RID_* values? > Also, I noted a few tests check for the int128-specific error message > when the type is not supported, but as per our previous discussion, > the __int128 keyword just doesn't exist if the type isn't supported. > Do we need to discern between "not supported with these options" and > "not supported ever" ? I don't think there's a need to distinguish, although I don't think it would be particularly harmful to have an __int128 keyword present without a corresponding type for targets not supporting __int128, if that helps diagnostics, as long as nothing else special-cases __int128. (Draft TS 18661-3 has the interesting peculiarity that the keywords _FloatN for N = 16, 32, 64 or >= 128 and a multiple of 32, _DecimalN for N >= 32 and a multiple of 32, and _Float32x, _Float64x, _Float128x, _Decimal64x, _Decimal128x always exist as keywords whether or not the corresponding types are supported. Implementing that would I suppose require special checks to handle arbitrary _FloatN and _DecimalN (for valid N) as keywords - an infinite number of keywords - much as we handle _Imaginary as a keyword without otherwise implementing it.) -- Joseph S. Myers joseph@codesourcery.com