Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:

> So I guess we just need
> 
> builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> builtin_define ("__builtin_nanq=__builtin_nanf128");
> 
> etc. to map the "q" builtins to "f128" builtins if we really need the
> "q" builtins.
> 
> Joseph: the problem here is many customers of LoongArch CPUs wish to
> compile their old code with minimal change.  Is it acceptable to add
> these builtin_define's like rs6000-c.cc?  Note "a new architecture" does
> not mean we'll only compile post-C2x-era programs onto it.

The powerpc support for __float128 started in GCC 6, predating the support 
for _FloatN type names, built-in functions etc. in GCC 7 - that's why 
there's such backwards compatibility support there.  That name only exists 
on a few architectures.

If people really want to compile code using the old __float128 names for 
LoongArch I suppose you could have such #defines, but it would be better 
for people to make their code use the standard names (as supported from 
GCC 7 onwards, though only from GCC 13 in C++) and then put backwards 
compatibility in their code for using the __float128 names if they want to 
support the type with older GCC (GCC 6 or before for C; GCC 12 or before 
for C++) on x86_64 / i386 / powerpc / ia64.  Such backwards compatibility 
in user code is more likely to be relevant for C++ than for C, given how 
the C++ support was added to GCC much more recently.  (Note: I haven't 
checked when other compilers added support for the _Float128 name or 
associated built-in functions, whether for C or for C++, which might also 
affect when user code wants such compatibility.)

-- 
Joseph S. Myers
joseph@codesourcery.com