> On 9 Apr 2025, at 09:00, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
> 
> Jakub Jelinek <ja...@redhat.com> writes:
> 
>> On Sun, Apr 06, 2025 at 09:02:07AM +0100, Iain Sandoe wrote:
>>> 
>>> +
>>> +#if !defined (HAVE_STRTOF128)
>>> +# if USE_QUADMATH
>>> +#  define strtof128 strtoflt128
>>> +# else
>>> +#  error "no available string to float 128"
>>> +# endif
>>> +#endif
>> 
>> If there is no strtof128 and not using libquadmath, there is always
>> the possibility to use strtold if long double is IEEE quad.
>> But that can be fixed incrementally.
>> 
>> As for strfromf128, there is always the possibility to use snprintf
>> with %.36LE format specifier if long double is IEEE quad.
> 
> That's what's needed on Solaris/SPARC which has _Float128, 128-bit long
> double, but no __float128 (yet, patch WIP).

OK - so you have the case:
 - long double == ieee753 128b float
 - no support for the io/transcendental functions in libc?

> There's one remaing issue in that case:
> 
> /vol/gcc/src/hg/master/cobol/libgcobol/intrinsic.cc:999:5: error: unsupported 
> non-standard suffix on floating constant
> 
> This needs
> 
> diff --git a/libgcobol/intrinsic.cc b/libgcobol/intrinsic.cc
> --- a/libgcobol/intrinsic.cc
> +++ b/libgcobol/intrinsic.cc
> @@ -67,7 +67,7 @@
> 
> #define JD_OF_1601_01_02 2305812.5
> 
> -#define WEIRD_TRANSCENDENT_RETURN_VALUE (0.0Q)
> +#define WEIRD_TRANSCENDENT_RETURN_VALUE GCOB_FP128_LITERAL (0.0)
> #define NO_RDIGITS (0)
> 
> struct cobol_tm
> 
> I guess it would be better to move that strtof128 and strfromf128
> handling to libgcobol-fp.h to avoid duplication.

I think that the right solution is probably to define something in  
libgcobol-fp.h that
shortens the tests, because IIRC we have to adapt the format string on the basis
of which case we have so some of the work cannot be completely moved to the
header.

Happy to do this incrementally or as a v2 - depending on the maintainer’s views.

Iain



> 
>       Rainer
> 
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to