On Wed, Nov 2, 2011 at 4:21 PM, Abramo Bagnara <[email protected]>wrote:
> Il 03/11/2011 00:16, Richard Trieu ha scritto: > > On Wed, Nov 2, 2011 at 3:51 PM, Abramo Bagnara <[email protected] > > <mailto:[email protected]>> wrote: > > > > Il 02/11/2011 03:21, Richard Trieu ha scritto: > > > On Mon, Oct 24, 2011 at 7:30 AM, Douglas Gregor <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > > > > On Oct 20, 2011, at 5:36 PM, Chandler Carruth wrote: > > > > > >> On Thu, Oct 20, 2011 at 5:12 PM, Richard Trieu > > <[email protected] <mailto:[email protected]> > > >> <mailto:[email protected] <mailto:[email protected]>>> wrote: > > >> > > >> Should Clang be printing suffixes that are accepted only > with > > >> certain flags? > > >> > > >> > > >> I think this is an interesting policy decision. I'd love to > hear > > >> Doug's thoughts on it. > > >> > > >> 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'. > > > > > > 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. > > > > > > … 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. > > > > > > - Doug > > > > > > > > > New patch. Changes as follows: > > > Add int128 and uint128 suffixes (i128 and Ui128) to StmtPrinter. > > short > > > and unsigned short will get to llvm_unreachable > > > Add assert to IntergerLiteral to prevent creation with type short > or > > > unsigned short > > > Fix comment in IntegerLiteral to say that int128 and uint128 are > > > acceptable types > > > Change BuildExpressFromIntegralTemplateArgument to give a proper > Expr. > > > For negative numbers, use UnaryOperator of IntegerLiteral. For > short > > > and unsigned short, ImplicitCastExpr from int. > > > > Following this path have you considered how to represent an int > > parameter with value INT_MIN? > > > > I think there is no way you can represent it in standard conformant > way > > except to use -INT_MAX - 1 (i.e. -2147483647 <tel:2147483647> - 1 if > > int has 32 bits). > > > > You cannot use -214783648 because no integer literal of type int with > > value 214783648 can exists. > > > > > > 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. > > What about when you don't have a larger type? (i.e. the minimum negative > number of larger signed integral type) > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
