Re: Converting mpz_t to different integer representations

[Brooks Moses <brooks dot moses at codesourcery dot com>]

Paul Thomas wrote:
> In making a patch for PR29786, I have met a problem with converting 
> mpz_t variables into a C type of known length len.  One way of doing 
> this is given in the patch attached to the PR; another is:
[...]

I'm not sure I understand very well what you're using this for -- and, 
in particular, why you're converting a mpz_t variable to a C type on the 
host rather than to a target representation.  If they're different, does 
this actually do the right thing with regard to endianness?  (Or, for 
that matter, with regard to floating-point representation with real 
numbers?)

I'll also note that I was begining to think about the need to write 
something almost exactly equivalent ot your expr_to_char() function, for 
implementing TRANSFER in initialization expressions.  In both cases, we 
need to convert things from a gfc_expr to a bitwise representation as it 
would be on the target.  So, if you can keep that in mind when you're 
writing yours, it will make doing TRANSFER a lot easier.  :)

Also, I guess the fact that this is needed for TRANSFER might make it a 
bit more encouraging to go to the trouble to write a proper set of 
routines to handle non-HOST endianness and float representations in 
converting GMP/MPFR representations to bitwise things.

- Brooks