<div class="gmail_quote">On Wed, Nov 2, 2011 at 3:51 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;">
<div class="im">Il 02/11/2011 03:21, Richard Trieu ha scritto:<br>
</div><div class="im">> On Mon, Oct 24, 2011 at 7:30 AM, Douglas Gregor <<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>>> 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 <<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>>> 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 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 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.  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>
</div></div>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>
except to use -INT_MAX - 1 (i.e. -<a href="tel:2147483647" value="+12147483647">2147483647</a> - 1 if int has 32 bits).<br>
<br>
You cannot use -214783648 because no integer literal of type int with<br>
value 214783648 can exists.<br></blockquote><div> </div></div>Richard Smith brought up a similar point in the code review comments.  I am putting in an integer type selector which will move up to larger types until a large enough type can be found.  For instance, for int_min, use the negation of a long with a cast back to int.