public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Meissner <meissner@linux.ibm.com>
To: Thomas Koenig <tkoenig@netcologne.de>
Cc: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	gcc mailing list <gcc@gcc.gnu.org>,
	Michael Meissner <meissner@linux.ibm.com>
Subject: Re: [power-ieee128] Which options for libquadmath / native ieee128
Date: Mon, 13 Dec 2021 17:00:27 -0500	[thread overview]
Message-ID: <YbfCe+t4aMcRn90+@toto.the-meissners.org> (raw)
In-Reply-To: <c03e7550-3186-4f59-b10a-98575ffe798a@netcologne.de>

On Mon, Dec 13, 2021 at 09:29:16PM +0100, Thomas Koenig wrote:
> 
> Hi,
> 
> looking at what the REAL(KIND=17) numbers should be compiled for, I see
> the following options that should be considered:
> 
> a) xsaddqp and friends are not supported by the CPU; libquadmath should
>    be called for all operations, including simple arithmetic.

Note, we do not use the emulator in libquadmath.  Libgcc has support for doing
software emulation of the IEEE 128-bit basic support.

> b) xsaddqp and friends are supported, but glibc is too old and lacks the
>    *ieee128 functions.  libquadmath should be called for these
>    functions.

Yes, this would be the place to call libquadmath.  Or possibly don't use
libquadmath at all and don't allow KIND=17.  It is probably better for the
users if we use libquadmath instead of disabling it all together.

> c) xsaddqp and friends are supported, and glibc is new enough.  Call
>    the *ieee128 functions.

The necessary support is in the little endian GLIBC 2.32 or newer.  I don't
recall if you also need Elf abi V2 (which is default on little endian).

You could check via:

	#if (((__GLIBC__ * 1000) + __GLIBC_MINOR__) >= 2032 && \
	     (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) \
	     (_CALL_ELF == 2))

If you are writing C code for the library, and using _Float128 for the type
instead of using long double and using the -mabi=ieeelongdouble switch, you
want to define the following macros before math.h or other system include files
are included:

	#define __STDC_WANT_IEC_60559_TYPES_EXT__	1
	#define __STDC_WANT_IEC_60559_FUNCS_EXT__	1

> What is the best way to check in the library config files that the quad
> precision instructions are supported (to differentiate between a) on the
> one hand and b) and c) on the other?

You can check whether long double is IEEE 128-bit via:

	#if defined(__LONG_DOUBLE_IEEE128__)		/* or */
	#if __LONG_DOUBLE_IEEE128__

and similarly to check for IBM 128-bit long double:

	#if defined(__LONG_DOUBLE_IBM128__)		/* or */
	#if __LONG_DOUBLE_IBM128__

To check whether IEEE 128-bit instructions are enabled:

	#if defined(__FLOAT128_HARDWARE__)		/* or */
	#if __FLOAT128_HARDWARE__

To check whether the _Float128 or __float128 keywords are available (whether or
not the hardware supports the instructions):

	#if defined(__FLOAT128_TYPE__)			/* or */
	#if __FLOAT128_TYPE__

Note, that C++ does not support the _Float128 type (which is in one of the IEC
papers), but it does support the non-standard __float128 keyword.
Unfortunately, __float128 _Complex does not work.  There is a GLIBC macro that
gives the appropriate _Complex type for __float128 use in C++, but I don't
remember what it is.

Alternatively, it might be simpler to build the library parts using long double
and build those modules with the appropriate options.

> 
> And which options to the compiler make sure the libquadmath library
> is called?

The libqaudmath library should always be linked in if it is built.  I had
actually meant to turn off building it once all of the 2.32 support went in,
but I never did.  Note, I haven't tested libquadmath in a long time.

To compile C/C++ code where long double is IEEE 128-bit use:

	-mabi=ieeelongdouble -Wno-psabi -mno-gnu-attribute

For Fortran code, I think you have to remove the -Wno-psabi.  But it may be
buggy.

Similarly to force long double to be IBM 128-bit, no matter what the defaults
are use:

	-mabi=iibmlongdouble -Wno-psabi -mno-gnu-attribute

The no-gnu-attribute says to disable setting the GNU attribute that says what
the default long double type is.  It is necessary when building libraries with
both 128-bit types.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

      reply	other threads:[~2021-12-13 22:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 20:29 Thomas Koenig
2021-12-13 22:00 ` Michael Meissner [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=YbfCe+t4aMcRn90+@toto.the-meissners.org \
    --to=meissner@linux.ibm.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=tkoenig@netcologne.de \
    /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).