<div class="gmail_quote">On Wed, Nov 2, 2011 at 4:21 PM, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Il 03/11/2011 00:16, Richard Trieu ha scritto:<br>
<div class="im">> On Wed, Nov 2, 2011 at 3:51 PM, Abramo Bagnara <<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a>>> wrote:<br>
><br>
>     Il 02/11/2011 03:21, Richard Trieu ha scritto:<br>
>     > On Mon, Oct 24, 2011 at 7:30 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a><br>
>     <mailto:<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>><br>
</div><div class="im">>     > <mailto:<a href="mailto:dgregor@apple.com">dgregor@apple.com</a> <mailto:<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>>>> wrote:<br>
>     ><br>
>     ><br>
>     >     On Oct 20, 2011, at 5:36 PM, Chandler Carruth wrote:<br>
>     ><br>
>     >>     On Thu, Oct 20, 2011 at 5:12 PM, Richard Trieu<br>
>     <<a href="mailto:rtrieu@google.com">rtrieu@google.com</a> <mailto:<a href="mailto:rtrieu@google.com">rtrieu@google.com</a>><br>
</div><div><div class="h5">>     >>     <mailto:<a href="mailto:rtrieu@google.com">rtrieu@google.com</a> <mailto:<a href="mailto:rtrieu@google.com">rtrieu@google.com</a>>>> wrote:<br>
>     >><br>
>     >>         Should Clang be printing suffixes that are accepted only with<br>
>     >>         certain flags?<br>
>     >><br>
>     >><br>
>     >>     I think this is an interesting policy decision. I'd love to hear<br>
>     >>     Doug's thoughts on it.<br>
>     >><br>
>     >>     It seems fine to me for Clang, when running with -fms-extensions,<br>
>     >>     to suggest fixes even if only valid for -fms-extensions. Clearly<br>
>     >>     if there is a generic suggestion that could be made, that<br>
>     would be<br>
>     >>     a preferred alternative. For example, '__asm__' should be<br>
>     >>     suggested before 'asm'.<br>
>     ><br>
>     >     I think it's fine for Clang to print suffixes that are only<br>
>     accepted<br>
>     >     with certain flags. Presumably, you should never get an<br>
>     >     IntegerLiteral of type __int128_t unless you're in a dialect that<br>
>     >     supports parsing it.<br>
>     ><br>
>     >     … except that we cheat when we're building template arguments,<br>
>     >     because it was convenient. That cheating could be eliminated by<br>
>     >     encoding integer literal values directly within<br>
>     >     SubstNonTypeTemplateParmExpr.<br>
>     ><br>
>     >     - Doug<br>
>     ><br>
>     ><br>
>     > New patch.  Changes as follows:<br>
>     > Add int128 and uint128 suffixes (i128 and Ui128) to StmtPrinter.<br>
>      short<br>
>     > and unsigned short will get to llvm_unreachable<br>
>     > Add assert to IntergerLiteral to prevent creation with type short or<br>
>     > unsigned short<br>
>     > Fix comment in IntegerLiteral to say that int128 and uint128 are<br>
>     > acceptable types<br>
>     > Change BuildExpressFromIntegralTemplateArgument to give a proper Expr.<br>
>     >  For negative numbers, use UnaryOperator of IntegerLiteral.  For short<br>
>     > and unsigned short, ImplicitCastExpr from int.<br>
><br>
>     Following this path have you considered how to represent an int<br>
>     parameter with value INT_MIN?<br>
><br>
>     I think there is no way you can represent it in standard conformant way<br>
</div></div>>     except to use -INT_MAX - 1 (i.e. -<a href="tel:2147483647" value="+12147483647">2147483647</a> <tel:<a href="tel:2147483647" value="+12147483647">2147483647</a>> - 1 if<br>
<div class="im">>     int has 32 bits).<br>
><br>
>     You cannot use -214783648 because no integer literal of type int with<br>
>     value 214783648 can exists.<br>
><br>
><br>
> Richard Smith brought up a similar point in the code review comments.  I<br>
> am putting in an integer type selector which will move up to larger<br>
> types until a large enough type can be found.  For instance, for<br>
> int_min, use the negation of a long with a cast back to int.<br>
<br>
</div>What about when you don't have a larger type? (i.e. the minimum negative<br>
number of larger signed integral type)<br>
</blockquote></div><br><div>I'm thinking of switching to the unsigned version of that signed type.  And if that is still not large enough, assert, because there's nothing left Clang can do.</div>