Re: RFC: gfc_simplify_transfer implementation.

[FX Coudert <fxcoudert at gmail dot com>]

First, congratulations on the good work!

> Meanwhile, the target-memory.c functions are in a sort of  
> preliminary state which assumes that the host and target have the  
> same memory representations, and thus don't work correctly on cross- 
> compilers. They are, however, written in a way that should make it  
> relatively easy to improve them and include proper target  
> representations.  And they do function properly for a native compiler.

Have you or Paul actually checked that they don't work correctly on  
cross-compilers? I think that at least the integer and real constants  
are stored in tress in host endianess (and thus, probably the logical  
and complex also work)...

For characters, there's a target hook to convert from host charset:  
it's lang_hooks.to_target_charset (see uses in trans-expr.c and in  
the middle-end).

For derived types, I don't know.

> I think the best plan is to do a little more polishing work on this  
> as it stands, and then commit it to mainline on the grounds that  
> it's at least a distinct improvement over the current form, even if  
> it's wrong for cross-compilers.

Well, I think we should really know exactly where we stand on the  
cross-compiler ground before commiting. Otherwise, we'll end up  
discovering the worst in a long time from now, and it will be one of  
these vicious wrong-code bugs :)

> I will then work on implementing the "right" sort of memory  
> transfer functions that don't piggyback off the host's memory  
> representation.

I don't think we gain so much from exposure by commiting early. The  
patch is not that large, I guess. Of course, as I'm not volunteering  
to do the hard job (sorry guys) I'm not opposing to whatever you decide.

> +static size_t
> +size_float (int kind)
> +{
> +  return kind;
> +}

So I take it it's a byte size, right? Why not make it a bit size, are  
we sure there's never a bit size involved? (hum, maybe not until  
bitfields are added as F2008, perhaps)

Also, we should really be getting those from the bit_size field of  
the gfc_{integer,logical}_info structures for integer and logical,  
and we should also add a similar field in the gfc_real_info  
structure. I think that otherwise, you can get the real(kind=10) size  
wrong, no?

FX