On Tue, 10 Dec 2013, DJ Delorie wrote: > > This seems mostly plausible, though I don't see anything to ensure that > > __intN does not exist at all if the size matches one of the standard C > > types, > > My thought here was that, since each __intN is specified by the > target, they'd know to only do so if it doesn't match an existing (for > that target) type. But what if it does? What if the standard types > changed based on command line options, and the target wanted to offer > an __intN as a "this will always work" alternative to standard types?
If you have such alternative types, you have extra complications: either they are the same as a standard type (and you need to define what the order of preference is and keep it constant, to avoid __intN changing from int to long at random), or they are distinct (and you need to define integer promotion ranks and ensure the front end code handles promotions for types the same size as int correctly). Not having such alternatives avoids such complications. Thus, I'd rather any possibility of such types came later after the basic support for types not matching the standard types. (For the types you do have, there's a need to define C++ name mangling. There are various other issues for such extended types - see PR 50441 comment 3, and PR 43622 - but you can safely ignore such issues for now as pre-existing problems with __int128. Whereas __int128 does have mangling defined in cp/mangle.c, and targets can already define their own mangling for target-specific types through a hook.) -- Joseph S. Myers jos...@codesourcery.com
