On Mon, Sep 08, 2025 at 04:03:21PM +0200, Jason Merrill wrote:
> On 9/8/25 8:11 AM, Matthias Kretz wrote:
> > Andrew Pinski [Friday, 5 September 2025, 22:57:02 CEST]:
> > > > It seems that Clang and GCC disagree on mangling 80-Bit long double:
> > > >
> > > > https://compiler-explorer.com/z/W1d64PjrP
> > > >
> > > > I like Clang's interpretation of
> > > > https://itanium-cxx-abi.github.io/cxx-abi/
> > > > abi.html#mangle.float better.
> > >
> > > "corresponding to the internal representation" But interpretations
> > > seems valid since there is no mention of the padding bits.
> > > I think GCC is better because it includes the full padding bits.
> >
> > I interpret "internal representation" to say that not the decimal value is
> > printed but rather the bits in memory that make up the floating-point value.
> > And padding bits don't contribute to that value.
> >
> > I wrote "like" above. I have no idea about the wording intent. But using the
> > shorter mangling, and a mangling that is the same on 32- and 64-bit seems
> > preferable. Which is why I "like" it more.
>
> I agree. Can you address that in this patch as well?
That would be an ABI change, so should depend on -fabi-version= because
unlike _Float16 or std::bfloat16_t literals, I think long double literals
will appear pretty frequently.
Also, the question is if we don't use the TYPE_SIZE_UNIT or TYPE_SIZE
to determine how many hex digits to print, what else should be used.
For decimal floating point, I think we need to keep doing what we used
before, the 32/64/128-bit case are desirable (though unsure if it is ok that
the dfp literals will mangle differently on s390/ppc compared to all other
targets because they use different encodings). Anyway, dfp has p (see
below) 7 (32 bits), 16 (64 bits) and 34 (128 bits).
For binary floating point, perhaps use
REAL_MODE_FORMAT (TYPE_MODE (type))->p ?
Looking through the
^const struct real_format cases in real.cc (and pdp11.cc), we have
p bits
8 16 std::bfloat16_t
11 16 std::float16_t
24 32 IEEE single and similar formats
53 64 IEEE double and similar formats
also ieee_extended_intel_96_round_53_format, dunno if we
want to handle that like 64-bit or 80-bit
56 64 VAX/PDP-11 d
64 80 Intel/Motorola extended
106 128 IBM double double
113 128 IEEE quad and similar formats
Now, I think TYPE_SIZE is the desirable one in all cases but the p 64 and
maybe 53 (for p 64 TYPE_SIZE I think can be 96 and 128 bits and for p 53
64, 96 and 128).
ieee_extended_intel_96_round_53_format is used e.g. on FreeBSD, it reflects
the use of the Intel 80-bit registers when the FPU is configured to round
everything to IEEE double.
Jakub
