On Sun, Sep 23, 2012 at 1:45 PM, Dmitri Gribenko <span dir="ltr"><<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, Sep 23, 2012 at 11:41 PM, Stephen Canon <<a href="mailto:scanon@apple.com">scanon@apple.com</a>> wrote:<br>
> On Sep 23, 2012, at 4:20 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br>
><br>
> Yes, currently it is misleading and just bad to turn on<br>
> -fms-extensions if one wants 128-bit literals.  Since this is not an<br>
> MS extension, code using this feature does not need other MS<br>
> extensions.<br>
><br>
> Should support be enabled by default as a clang extension?<br>
<br>
</div>I would say yes, but since a new kind of integer literal is such a big<br>
thing, we definitely need a comment from our honorable C++ language<br>
layers who working on Clang.</blockquote><div><br></div><div>There are three interactions with language law that seem relevant here:</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>My recommendation is: we drop the GNU extension, implement the C99 / C++11 extended integer type rules instead, and drop the i128 suffix.</div><div><br></div><div>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.</div>
<div><br></div><div>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!).</div>
<div><br></div><div>-- Richard</div></div>