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

[Richard Smith]

On Mon, Sep 24, 2012 at 4:14 AM, Stephen Canon <scanon at apple.com> wrote:

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

Sorry, I could have been much clearer there! That applies to decimal
integer literals with no suffix. You would be able to get an unsigned
__int128 by using either (1) a literal which does not fit in 64 bits, with
a suffix containing 'u', or (2) a hexadecimal or octal literal which does
not fit into a signed __int128.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120924/6612f329/attachment.html>