On Mon, Sep 08, 2025 at 05:40:00PM +0200, Jason Merrill wrote:
> > 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 ?
>
> How about MODE_PRECISION (TYPE_MODE (type))?
At least in the past MODE_PRECISION of scalar float modes has been pretty
wild (e.g. on powerpc 126, 127 or 128 bits).
I see it is now 128 bits on the trunk, so maybe it could work too.
Though the question what to do about FreeBSD still remains, seems clang
doesn't bother and mangles it as 80 bit and uses __LDBL_* constants for
Intel extended even when the crt files on FreeBSD restrict to 53 bits
precision.
Though, my reading of what gcc does is that it allows the exponent to have
the Intel Extended range and just the precision be more limited, so 64
bits aren't enough to express it, so maybe 80 are the only way (or 1+15+53
?).
Another question is m68k, it has a variant of big endian Intel extended,
80-bits precision I think but sign bit is bit 95.
1.0L right now mangles there as
3fff00008000000000000000
so if we wanted to mangle it as
3fff8000000000000000
we'd need to special case ieee_extended_motorola_format
or check for p 64 and signbit_ro 95 and perhaps bitsize 80 and deal with it.
On x86_64 we mangle it as
0000000000003fff8000000000000000
and on ia32 as
00003fff8000000000000000
Yet another option would be keep doing what we were doing unless
GET_MODE_PRECISION is 80, in which case deal with the 2 variants based on
signbit_ro value.
Jakub
