<div class="gmail_quote">On Wed, Nov 2, 2011 at 4:49 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com">rtrieu@google.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="HOEnZb"><div class="h5"><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" target="_blank">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>> On Wed, Nov 2, 2011 at 3:51 PM, Abramo Bagnara <<a href="mailto:abramo.bagnara@gmail.com" target="_blank">abramo.bagnara@gmail.com</a><br>
</div><div>> <mailto:<a href="mailto:abramo.bagnara@gmail.com" target="_blank">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" target="_blank">dgregor@apple.com</a><br>
> <mailto:<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>><br>
</div><div>> > <mailto:<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a> <mailto:<a href="mailto:dgregor@apple.com" target="_blank">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" target="_blank">rtrieu@google.com</a> <mailto:<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a>><br>
</div><div><div>> >> <mailto:<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a> <mailto:<a href="mailto:rtrieu@google.com" target="_blank">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" target="_blank">2147483647</a> <tel:<a href="tel:2147483647" value="+12147483647" target="_blank">2147483647</a>> - 1 if<br>
<div>> 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></div><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>
</blockquote></div><br><div>Another patch. Have the integer type change to a larger type if the current one isn't big enough. Signed and unsigned chars will be cast integer literals instead of character literals. Moved the implicit cast to be the outermost expression.</div>