This is the mail archive of the gcc-bugs@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]

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-06-30 22:27:57 UTC ---
On Thu, 30 Jun 2011, sandals at crustytoothpaste dot net wrote:

> Your only out here is if you claim that the type in question (however named,
> unnamed, or specified) is not an implementation-defined signed integer type,
> and in that case, you'll need to specify that in the documentation and specify
> what it *is*.  You should probably document that it is a) not
> implementation-defined, b) not signed (or unsigned, as appropriate), c) not
> integral, or d) not a type.

The implementation-defined extended integer types are documented alongside 
the other implementation-defined behavior in implement-c.texi: "GCC does 
not support any extended integer types.".

Note that "char" is a standard integer type that is not a signed or 
unsigned integer type although it behaves like one or the other; you could 
think of it as a "sui generis integer type".  And the right way to think 
of __int128 is as a "sui generis extended type", that is not an integer 
type although it shares some properties with them.  Maybe the __fpreg type 
supported on IA64 is more obviously a "sui generis extended type" given 
the restrictions on how it can be used - but the same category contains 
both those types (and ARM __fp16, for another example).


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