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

[sandals at crustytoothpaste dot net]

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

--- Comment #10 from brian m. carlson <sandals at crustytoothpaste dot net> 2011-06-30 21:47:15 UTC ---
(In reply to comment #9)
> What do you mean by standards mode?
> It's clearly documented in the manual that -std=c99 does NOT mean non-standard
> extensions are rejected, for that you need to use -pedantic-errors, and that
> rejects __int128.

My complaint is not even about __int128.  My complaint is about intmax_t.  With
-std=c99, intmax_t is not capable of representing all the values of all
implementation-defined signed integer types.  The C standard requires that it
is so capable.  If the implementation provides a type (however named (or
unnamed) or specified) that is an implementation-defined signed integer type,
intmax_t must be capable of expressing all the values that such a type may
hold.

I don't care how the type is specified or named.  It exists.  It happens to be
named in the standard-specified manner; that is convenient, but ultimately
irrelevant. It exists, therefore, intmax_t's behavior is specified in terms of
that type. Period.

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.