https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113511
--- Comment #2 from gaiusmod2 at gmail dot com ---
"rguenth at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> writes:
> There's also the question on compatibility to libgm2 from GCC 13.
indeed - I guess the -mabi could be retained for backward compatibility.
> I suppose the frontend could simply not allow changing the M2 language
> "long double" (however it is called) with -mabi=... (which really only
> change the C language ABI!). Of course calls to libm are subject to the
> C language ABI.
ok yes. So m2's longreal data type uses ieeelongdouble throughout by
default on powerpc - that would be clean.
In principle could all the C interface from m2 code convert the longreal
representation to glibc long double and visa versa?
So for example in the case of libm.def
change libm.def from a DEFINITION FOR "C" to an ordinary m2 definition
module. Introduce libm.c which for non power platforms just passes
calls though to C. On powerpc (without an IEEE128 glibc) it will
convert __float128 onto the underlying long double representation.
> Does the language standard have anything to say here? I suppose there's
> no ABI documents for M2 for various targets, so eventually C interoperability
> language in the standard directs at the common sense?
It leaves much to be implementation defined :-)
The gcc/m2/gm2-libs-iso/LowLong.def provides setMode which could be used
to control the behaviour of the above conversions. The size of the set
Modes and their meaning is implementation defined.
Possibly it might be implemented:
Bit 0: issue an error and abort if the underlying long double support
in glibc does not match the longreal in m2.
Bit 1: issue a single warning if the underlying long double support
in glibc does not match the longreal in m2 and then attempt
conversion.
Bit 2: raise an exception if the underlying long double support
in glibc does not match the longreal in m2.
Bit 3: raise an exception if the conversion between longreal and
glibc C long double representations exceeds range.
Bit 4.. More bits to control conversion behaviour.
[ as a start ]
