> -----Original Message-----
> From: Richard Biener <[email protected]>
> Sent: Friday, March 28, 2025 08:12
> To: Jakub Jelinek <[email protected]>
> Cc: [email protected]; [email protected]
> Subject: Re: [PATCH] [COBOL] use native_encode_real
>
> 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.
I see it has been pushed. I just ran it through my existing test gamut on
x86_64. It behaves as expected.
>
> > 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.
