public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "gaiusmod2 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug modula2/113511] lack of libm2 ABI compatibility on powerpc platforms
Date: Tue, 23 Jan 2024 10:54:58 +0000	[thread overview]
Message-ID: <bug-113511-4-2JRd3DHpTy@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113511-4@http.gcc.gnu.org/bugzilla/>

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 ]

      parent reply	other threads:[~2024-01-23 10:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 23:09 [Bug modula2/113511] New: " gaius at gcc dot gnu.org
2024-01-22  8:51 ` [Bug modula2/113511] " rguenth at gcc dot gnu.org
2024-01-23 10:54 ` gaiusmod2 at gmail dot com [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-113511-4-2JRd3DHpTy@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).