This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch]: Add support of new __int128 type for targets having 128-bit integer scalar support


On Tue, 25 May 2010, Paolo Carlini wrote:

> By the way, if people interested in types __int128 and __uint128 are
> willing to have a look to libstdc++/40856, I attached there a patch
> implementing numeric_limits<__int128> and numeric_limits<__uint128>

Note that the preferred names (with Kai's patch applied) are __int128 and 
unsigned __int128 (not the old typedefs __int128_t and __uint128_t that 
are in your patch) - these names come from the x86_64 ABI.  The __int128 
keyword has the advantage that, being a keyword rather than a typedef, it 
can be used with "unsigned" (and C99 _Complex / GNU __complex__).

Do we have a rule for when there is C++ support (numeric_limits, RTTI and 
whatever else libstdc++ does for each integer or each floating-point type) 
for extended types?  This issue applies not just to __int128 and unsigned 
__int128, but also for __float128 and __float80 when they are supported 
(on x86/x86_64 and IA64) and distinct from long double (on IA64, long 
double may be either __float128 or __float80 depending on the target OS) 
and for half-precision floating-point (ARM __fp16 - though the promotions 
applied to that type may reduce the number of cases in which it is 
relevant).  Note that if you rely on C library support for printing etc. 
the C library may not support these types, and that __int128 is not an 
extended integer type in C99 terms because the ABI setting intmax_t to 
long long was previously fixed.  I guess the issue recently raised for 
libgfortran and __float128 is similar....

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]