On Thu, 14 Nov 2013, DJ Delorie wrote: > > Instead of a target-independent __int128 keyword, there would be a set > > (possibly empty) of __intN keywords, determined by a target hook. > > Or *-modes.def ?
That would be one possibility - if the idea is to define __intN for all integer modes not matching a standard type (and passing targetm.scalar_mode_supported_p), I advise posting details of what effect this would have for all targets so we can see how many such types would get added. (I don't advise having __intN when there are matching standard integer types as that would introduce unnecessary complications regarding whether __intN is the same type, or a distinct one needing its own name mangling and rank for promotion. Draft TS 18661-3 does have _Float32 etc. as always distinct types from float etc., but I don't see any use for that for integer types for now.) -- Joseph S. Myers jos...@codesourcery.com
