On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> I don’t like the _Float128 vs __float128 business, it’s confusing.
> And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> they seem to be basically the same thing, so it’s also redundant.
I thought __float128 and _Float128 are distinct and incompatible in the FEs
and equivalent in middle-end and back-end, but apparently they are
considered equivalent even for _Generic.
Still, using __float128 when the APIs are declared for __float128 and
_Float128 when the APIs are declared for _Float128 can be better for
consistency.
But if you feel strongly that we should use _Float128 and F128/f128
suffixes on floating point constants everywhere, we'd need more work
(e.g. because we use those same suffixes also for the functions where
we need to differentiate, or on macros like M_PI etc. where it is
significant too), and we'd need to come up with new macros to differentiate
which API set to use.
In the patch I've posted,
HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 defines stand for
__float128 + libquadmath APIs,
HAVE__FLOAT128 and GFC_REAL_16_IS__FLOAT128 stand for
_Float128 and C *f128 APIs.
If HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 stand for
_Float128 and libquadmath or *f128 APIs, we'd need some macro
to tell which APIs to use, say
USE_LIBQUADMATH and USE_IEC_60559.
And the hardest part would be that we that GFC_REAL_{16,17}_LITERAL{,_SUFFIX}
is currently used everywhere while for library APIs and M_* constants
we need to differentiate. Perhaps we could just use *q suffixes even when
using _Float128 when USE_LIBQUADMATH.
Jakub
