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

[Richard Smith]

Incidentally, we currently treat (for instance) 1000000000000000000i32 as a
64-bit integer. How does MSVC behave here? (Does i32 mean "this shall be an
int32_t", or does it mean "this shall be *at least* an int32_t"?)

If we choose to keep the i128 suffix, it should match i32 and i64, and
always give an __int128 (since we have no larger integer types).

On Sun, Sep 23, 2012 at 9:37 PM, 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.
>
> 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/4c78a935/attachment.html>