Re: proposal to make SIZE_TYPE more flexible

[DJ Delorie <dj@redhat.com>]

> 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?

I did code it such that standard types are preferred over __intN types
in the searches.

> or if the mode fails targetm.scalar_mode_supported_p.

As I mentioned, I haven't added that part yet.  My though there is to
add a runtime flag to the int_n_trees[] array and have each loop over
that data check the flag.  I suppose I could check for the types being
NULL but IIRC there are cases that only use the genmodes data and not
the types.  For aesthetic reasons I wanted to keep the flag separate.

> (To move __int128 to this system, given that its availability will

I put all the new code alongside the __int128 code, so the __int128
code can just be cut out after the new code is in place, but that's
down the road a bit.