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
jos...@codesourcery.com
