[Bug modula2/113511] New: lack of libm2 ABI compatibility on powerpc platforms

[Bug modula2/113511] New: lack of libm2 ABI compatibility on powerpc platforms

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113511

            Bug ID: 113511
           Summary: lack of libm2 ABI compatibility on powerpc platforms
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: modula2
          Assignee: gaius at gcc dot gnu.org
          Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Following on from PR111956 gm2 can generate objects using -mabi=ibmlongdouble
and -mabi=ieeelongdouble.  However it only links to the libgm2 generated using
the
--with-long-double-128 and --with-long-double-format flags selected during
configure.

[Bug modula2/113511] lack of libm2 ABI compatibility on powerpc platforms

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113511

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |powerpc*
           Keywords|                            |ABI

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's also the question on compatibility to libgm2 from GCC 13.

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.

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?

[Bug modula2/113511] lack of libm2 ABI compatibility on powerpc platforms

[gaiusmod2 at gmail dot com]

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-bugzilla@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 ]