RFC: gfc_simplify_transfer implementation.
FX Coudert
fxcoudert@gmail.com
Tue Mar 27 22:05:00 GMT 2007
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
More information about the Gcc-patches
mailing list