On Wed, 13 Nov 2013, DJ Delorie wrote: > I tried to hack in support for intN_t in a backend, and it was a maze > of initialization sequence nightmares. So I guess we need to do the > intN_t part first. Is someone working on this? If not, is there a > spec I could use to get started on it?
Instead of a target-independent __int128 keyword, there would be a set (possibly empty) of __intN keywords, determined by a target hook. Everything handling __int128 would be updated to work with a target-determined set of types instead. Preferably, the number of such keywords would be arbitrary (so I suppose there would be a single RID_INTN for them) - that seems cleaner than the system for address space keywords with a fixed block from RID_ADDR_SPACE_0 to RID_ADDR_SPACE_15. -- Joseph S. Myers jos...@codesourcery.com
