On Thu, Apr 10, 2025 at 07:21:23PM +0100, Iain Sandoe wrote:
> > So, here is an updated patch based on your patch, so far briefly
> > tested on x86_64 with recent glibc (i.e. with the *f128 APIs).
>
> makes sense to me - and builds and tests on x86_64-darwin (which needs
> libquadmath) without issue.
Bootstrapped/regtested on x86_64-linux too (with f128 APIs in glibc,
so not using libquadmath) and built/regtested on aarch64-linux with
old glibc (so IEEE quad long double, no f128 APIs in glibc, not using
libquadmath).
> > 2025-04-10 Jakub Jelinek <ja...@redhat.com>
> > Rainer Orth <r...@cebitec.uni-bielefeld.de>
> >
> > PR cobol/119244
> > * acinclude.m4 (LIBGCOBOL_CHECK_FLOAT128): Ensure
> > libgcob_cv_have_float128 is not yes on targets with IEEE quad
> > long double. Don't check for --as-needed nor set LIBQUADSPEC
> > on targets which USE_IEC_60559.
> > * libgcobol-fp.h (FP128_FMT, strtofp128, strfromfp128): Define.
> > * intrinsic.cc (strtof128): Don't redefine.
> > (WEIRD_TRANSCENDENT_RETURN_VALUE): Use GCOB_FP128_LITERAL macro.
> > (__gg__numval_f): Use strtofp128 instead of strtof128.
> > * libgcobol.cc (strtof128): Don't redefine.
> > (format_for_display_internal): Use strfromfp128 instead of
> > strfromf128 or quadmath_snprintf and use FP128_FMT in the format
> > string.
> > (get_float128, __gg__compare_2, __gg__move, __gg__move_literala):
> > Use strtofp128 instead of strtof128.
> > * configure: Regenerate.
Jakub
