Jakub Jelinek 69ffddd8bd libgcobol: Handle long double as an alternate IEEE754 quad [PR119244] ...

I think there should be consistency in what we use, so like
libgcobol-fp.h specifies, IEEE quad long double should have highest
priority, then _Float128 with *f128 APIs, then libquadmath.
And when we decide to use say long double, we shouldn't mix that with
strfromf128/strtof128.

Additionally, given that the *l vs. *f128 vs. *q API decision is done
solely in libgcobol and not in the compiler (which is different from
the Fortran case where compiled code emits say sinq or sinf128 calls),
I think libgcobol.spec should only have -lquadmath in any form only in
the case when using libquadmath for everything.  In the Fortran case
it is for backwards compatibility purposes, if something has been
compiled with older gfortran which used say sinq and link is done by
gfortran which has been configured against new glibc with *f128, linking
would fail otherwise.

2025-04-15  Jakub Jelinek  <jakub@redhat.com>
	    Rainer Orth  <ro@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.

2025-04-15 07:55:55 +02:00

6.5 KiB

Raw Permalink Blame History

View Raw