public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Michael Meissner <meissner@linux.ibm.com>,
	gcc@gcc.gnu.org, Thomas Koenig <tkoenig@netcologne.de>,
	fortran@gcc.gnu.org, Tobias Burnus <tobias@codesourcery.com>,
	Jonathan Wakely <jwakely@redhat.com>
Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
Date: Thu, 14 Oct 2021 19:16:54 -0500	[thread overview]
Message-ID: <20211015001654.GI614@gate.crashing.org> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2110112002300.1524986@digraph.polyomino.org.uk>

Hi!

On Mon, Oct 11, 2021 at 08:11:50PM +0000, Joseph Myers wrote:
> On Fri, 8 Oct 2021, Segher Boessenkool wrote:
> > But many CPUs do not have hardware floating point in any variant, and
> > their ABIs / calling conventions do not mention floating point at all.
> > Still, this works with GCC just fine: it passes floats and doubles the
> > same as 32-bit resp. 64-bit integers.
> > 
> > binary16 and bfloat16 would be easy to support the same way, but it is a
> > bit harder for binary128, because we do not have a 128-bit integer type
> 
> Supporting passing arguments (and return values) the same as an integer 
> type of the same size is a *choice* (which comes with other choices - in 
> particular, whether to say some or all the higher bits in the register or 
> stack slot are sign-extended, zero-extended or undefined).  It's a choice 
> that should be made explicitly, and documented (in the relevant ABI if one 
> is maintained), and coordinated between implementations when there's more 
> than one implementation for the architecture trying to be compatible.  

I don't disagree at all.  But: GCC makes that choice for you, if you do
not.  Many (embedded and/or older) targets do not.  They get the
defaults, those just work, and /de facto/ become the standard.

In practice most such architectures are purely 32-bit, so there is no
sign/zero extension problem.

> We've had plenty of problems in the past with ABIs that were just what 
> happened to fall out of the implementation (e.g. ABIs that depended on the 
> details of what machine mode was assigned to a structure type...).

Yes.

And we still have problems on older ABIs with e.g. new C++ requirements
that did not exist >25 years ago when the ABIs were written.  Not all of
this can be helped at all.

> On a related note, I'd encourage architecture maintainers to start 
> thinking now about what exactly their ABIs should be for _BitInt 
> (<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf>, accepted as 
> a required feature for C23 up to at least the width of unsigned long 
> long), and documenting it and coordinating with other implementations 
> where appropriate.  There's a concrete proposal for x86_64 (see 
> origin/usr/hjl/bitint branch at 
> https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an 
> indication of the sort of issues to address in such an ABI.

This should really go on gcc@, in a thread of its own, and a wiki page
might help as well?


Segher

  reply	other threads:[~2021-10-15  0:18 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 10:07 Jakub Jelinek
2021-10-04 11:24 ` Richard Biener
2021-10-04 11:36   ` Jakub Jelinek
2021-10-04 12:31     ` Jakub Jelinek
2021-10-04 14:14 ` Jakub Jelinek
2021-10-04 16:47   ` Joseph Myers
2021-10-04 18:33   ` Segher Boessenkool
2021-10-04 19:24     ` Joseph Myers
2021-10-05 17:43       ` Segher Boessenkool
2021-10-14 19:39         ` Bill Schmidt
2021-10-15  0:26           ` Segher Boessenkool
2021-10-05 20:16   ` Thomas Koenig
2021-10-05 21:54     ` Segher Boessenkool
2021-10-06  6:59       ` Thomas Koenig
2021-10-06 15:17         ` Segher Boessenkool
2021-10-06 15:41           ` Jakub Jelinek
2021-10-06 16:07             ` Segher Boessenkool
2021-10-06 16:34               ` Jakub Jelinek
2021-10-06 16:59                 ` Segher Boessenkool
2021-10-06 17:07                   ` Jakub Jelinek
2021-10-06 17:50                     ` Segher Boessenkool
2021-10-06 19:30                       ` Peter Bergner
2021-10-06 17:13                 ` Joseph Myers
2021-10-06 18:39                   ` Segher Boessenkool
2021-10-06 19:42                     ` Joseph Myers
2021-10-06 20:57                       ` Segher Boessenkool
2021-10-06 21:55                         ` Joseph Myers
2021-10-06 22:03                         ` Joseph Myers
2021-10-08 17:53                           ` Segher Boessenkool
2021-10-11 20:11                             ` Joseph Myers
2021-10-15  0:16                               ` Segher Boessenkool [this message]
2021-10-06 15:42           ` David Edelsohn
2021-10-06 16:19             ` Segher Boessenkool
2021-10-06 17:38               ` David Edelsohn
2021-10-07  3:42           ` Michael Meissner
2021-10-08 21:10             ` Segher Boessenkool
2021-10-07  9:48         ` Alastair McKinstry
2021-10-07  9:56           ` Andreas Schwab
2021-10-07 10:01             ` Jakub Jelinek
2021-10-07 12:43               ` Alastair McKinstry
2021-10-05 21:53   ` Jonathan Wakely
2021-10-07  3:35 ` Michael Meissner
2021-10-07  6:08   ` Thomas Koenig
2021-10-07  9:40     ` Jakub Jelinek
2021-10-07 15:24     ` Michael Meissner
2021-10-07 15:33       ` Jakub Jelinek
2021-10-08  6:35         ` Thomas Koenig
2021-10-08  7:20           ` Iain Sandoe
2021-10-08 16:26             ` Thomas Koenig
2021-10-08 19:11               ` Iain Sandoe
2021-10-08 22:55                 ` Thomas Koenig
2021-10-08 23:18                   ` Iain Sandoe
2021-10-09  9:11                     ` Thomas Koenig
2021-10-09  9:19                       ` Iain Sandoe
2021-10-09  9:25                       ` Jakub Jelinek
2021-10-09  7:44                   ` Andreas Schwab
2021-10-10 16:14                     ` Florian Weimer
2021-10-15 13:50 ` Bill Schmidt
2021-10-15 14:20   ` Jakub Jelinek
2021-10-15 18:05     ` Thomas Koenig
2021-10-15 18:11       ` Jakub Jelinek
2021-10-15 18:58         ` Thomas Koenig
2021-10-15 22:24     ` Segher Boessenkool
2021-10-15 22:36   ` Segher Boessenkool
2021-10-18 19:02   ` Joseph Myers
2021-10-28  3:10 ` Michael Meissner
2021-10-29  3:36 ` libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches) Michael Meissner
2021-10-29 19:07   ` Thomas Koenig
2021-10-29 21:06     ` Michael Meissner
2021-11-01 15:56       ` Bill Schmidt
2021-11-02 15:40         ` Michael Meissner
2021-10-29 21:21   ` Bernhard Reutner-Fischer
2021-10-29 22:23     ` Michael Meissner
2021-10-30  0:16 ` libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch) Michael Meissner
2021-10-30  9:30   ` Thomas Koenig
2021-10-30 10:03     ` Jakub Jelinek
2021-10-30 10:31       ` Thomas Koenig

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=20211015001654.GI614@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=jwakely@redhat.com \
    --cc=meissner@linux.ibm.com \
    --cc=tkoenig@netcologne.de \
    --cc=tobias@codesourcery.com \
    /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).