Converting mpz_t to different integer representations

[Paul Thomas]

Steve and Brooks,
> I read PR29786 and must admit I'm confused at what you're trying
> to do.  
An equivalence group is turned into a union, which contains fields with 
all manner of offsets and, potentially differnt types and kinds.  Adding 
initializers on top of this causes something of a complication because 
the data can be interleaved but not overlap.  There is then a choice as 
to what to do:
(i) Make a structure with separate fields for every data value.
(ii) Write the initializer data out into an array that holds it in 
native form and to use this as the initializer for an int8_t field that 
spans the union.

I chose to do the latter on grounds, I thought at the time, of 
simplicity :-) ...I also had the solution of PR18769 in mind because 
(ii) is what I had already done towards it.
>
> Of course, you would also need BT_CHARACTER and BT_COMPLEX.  For
> BT_DERIVED, a recursive function could build up the storage size.
>   
My question concerns which native integer kinds are guaranteed to be 
present and which ones require an
#if __int64_t_present (or whatever is appropriate).   Are int2_t, int4_t 
and int_8 type always present in platforms that gcc supports?
> Note to avoid hardcoded numbers here, you can use information 
> from gfc_real_info, gfc_logical_info, and gfc_integer_info.
>   
That is done to obtain len from type/kind.

Maybe (i) was better...

Paul