<div class="gmail_quote">On Mon, Oct 24, 2011 at 7:30 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Oct 20, 2011, at 5:36 PM, Chandler Carruth wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Thu, Oct 20, 2011 at 5:12 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com" target="_blank">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>Should Clang be printing suffixes that are accepted only with certain flags?</div><div><div></div></div></blockquote></div><div><br></div><div>I think this is an interesting policy decision. I'd love to hear Doug's thoughts on it.</div>

<div><br></div><div>It seems fine to me for Clang, when running with -fms-extensions, to suggest fixes even if only valid for -fms-extensions. Clearly if there is a generic suggestion that could be made, that would be a preferred alternative. For example, '__asm__' should be suggested before 'asm'.</div>
</blockquote><br></div></div></div><div>I think it's fine for Clang to print suffixes that are only accepted with certain flags. Presumably, you should never get an IntegerLiteral of type __int128_t unless you're in a dialect that supports parsing it.</div>
<div><br></div><div>… except that we cheat when we're building template arguments, because it was convenient. That cheating could be eliminated by encoding integer literal values directly within SubstNonTypeTemplateParmExpr.</div>
<div><br></div><div><span style="white-space:pre-wrap"> </span>- Doug</div><br></div></blockquote></div><div><br></div><div>New patch.  Changes as follows:</div><div>Add int128 and uint128 suffixes (i128 and Ui128) to StmtPrinter.  short and unsigned short will get to llvm_unreachable</div>
<div>Add assert to IntergerLiteral to prevent creation with type short or unsigned short</div><div>Fix comment in IntegerLiteral to say that int128 and uint128 are acceptable types</div><div>Change BuildExpressFromIntegralTemplateArgument to give a proper Expr.  For negative numbers, use UnaryOperator of IntegerLiteral.  For short and unsigned short, ImplicitCastExpr from int.</div>
<div><br></div><div>Basically, protect IntegerLiteral being shorts, fix the only case of short IntegerLiterals, and add support for printing int128 IntegerLiterals.  </div><div><br></div><div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); ">
PR:</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); "><a href="http://llvm.org/bugs/show_bug.cgi?id=11179" target="_blank" style="color: rgb(17, 85, 204); ">http://llvm.org/bugs/show_bug.cgi?id=11179</a></div>
<div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); "><br></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); ">
Patch also located at:</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgba(255, 255, 255, 0.917969); "><a href="http://codereview.appspot.com/5309045/" target="_blank" style="color: rgb(17, 85, 204); ">http://codereview.appspot.com/5309045/</a></div>
</div>