This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: gfc_simplify_transfer implementation.

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]