This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 30 Jun 2011 22:28:14 +0000
- Subject: [Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)
- Auto-submitted: auto-generated
- References: <bug-49595-4@http.gcc.gnu.org/bugzilla/>
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).