On Fri, 28 Mar 2025, Jakub Jelinek wrote:
> On Fri, Mar 28, 2025 at 08:54:53AM +0100, Richard Biener wrote:
> > The following avoids the round-trip through a newly built tree and
> > instead directly uses the now exported native_encode_real.
> >
> > Tested on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> > gcc/cobol/
> > * genapi.cc (initial_from_float128): Use native_encode_real.
>
> LGTM.
Will push later.
> Note, we still have at least
> /* ??? Use native_encode_* below. */
> retval = (char *)xmalloc(field->data.capacity);
> switch(field->data.capacity)
> {
> case 1:
> *(signed char *)retval = (signed char)i.slow ();
> break;
> case 2:
> *(signed short *)retval = (signed short)i.slow ();
> break;
> case 4:
> *(signed int *)retval = (signed int)i.slow ();
> break;
> case 8:
> *(signed long *)retval = (signed long)i.slow ();
> break;
> case 16:
> *(unsigned long *)retval = (unsigned long)i.ulow ();
> *((signed long *)retval + 1) = (signed long)i.shigh ();
> break;
> that needs some endian handling (and is also wrong for
> hosts which don't have 1 byte chars, 2 byte shorts, 4 byte ints
> and 8 byte longs), dunno if we want a round-trip through wide_int_to_tree
> and native_encode_expr in that case or if we do similar hack with exporting
> native_encode_int's helper or native_encode_int itself which will accept
> wide_int + type rather than tree.
IMO exporting a native_encode_wide would be nice.
> And I'm sure trying to do a cross from powerpc-linux to x86_64-linux
> will show up tons of other problems.
For sure.
Richard.
