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

[Stephen Canon]

On Sep 24, 2012, at 12:37 AM, Richard Smith <richard at metafoo.co.uk> wrote:

> 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.

As the only current user(?) of 128b literals, I like this approach.  I'm a little worried about the interaction with what you say about C++11, however: "an implementation must either give the constant a signed type large enough to hold it, or produce a diagnostic"; how does the user specify a 128b unsigned literal that is too large for 128b signed?

- Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120924/0f19bbb6/attachment.html>