[cfe-dev] MS 128-bit literals don't always have the correct type

[Richard Smith]

On Sun, Sep 23, 2012 at 1:45 PM, Dmitri Gribenko <gribozavr at gmail.com>wrote:

> On Sun, Sep 23, 2012 at 11:41 PM, Stephen Canon <scanon at apple.com> wrote:
> > On Sep 23, 2012, at 4:20 PM, Dmitri Gribenko <gribozavr at gmail.com>
> wrote:
> >
> > Yes, currently it is misleading and just bad to turn on
> > -fms-extensions if one wants 128-bit literals.  Since this is not an
> > MS extension, code using this feature does not need other MS
> > extensions.
> >
> > Should support be enabled by default as a clang extension?
>
> I would say yes, but since a new kind of integer literal is such a big
> thing, we definitely need a comment from our honorable C++ language
> layers who working on Clang.


There are three interactions with language law that seem relevant here:

1) C99 and C++11 have a notion of "extended integer types", which allows
for an integer literal (with or without a suffix) to be given a type larger
than any standard integer type, if it would be too large to fit in any
relevant standard integer type. We are not required to give __int128 this
treatment, but are permitted to do so. If we treated __int128 as an
extended integer type, we wouldn't need a suffix for this, except for cases
where the programmer explicitly want to get an __int128 result for a number
that would fit in 64 bits, and the i128 suffix does not provide us with
that behavior.

2) We support a GNU extension where a decimal integer literal which doesn't
fit in the largest standard signed type is given the largest standard
unsigned type instead, and that directly conflicts with the newer language
standards. This is not a conforming extension in C++11, where an
implementation must either give the constant a signed type large enough to
hold it, or produce a diagnostic (we get by here on a technicality, since
we produce a warning for this case, but we currently fail to reject it in
-pedantic-errors mode).

3) The new i128 suffix conflicts with C++11's user-defined literals.
However, that suffix (and all others not starting with an underscore) are
reserved ("for future standardization"), so using this suffix for our own
purposes is defying the intent of the committee, but still conforming.

My recommendation is: we drop the GNU extension, implement the C99 / C++11
extended integer type rules instead, and drop the i128 suffix.

It seems unlikely that anyone was relying on the suffix, since it is
undocumented, only works in -fms-extensions mode but isn't an MS extension,
and relies on the GNU __int128 type but isn't implemented in GCC... and in
any case the new rules would make it redundant.

Dropping the GNU extension could possibly impact the meaning of some (C++)
code which cares about the type of an overlarge integer literal, so we
should produce a diagnostic under -Wgcc-compat in the cases whose meanings
change. These are the cases where we currently produce an "integer constant
is so large that it is unsigned" warning (by default, with no flag to
disable it!).

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120923/6763bd2c/attachment.html>