public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [power-ieee128] Which options for libquadmath / native ieee128
@ 2021-12-13 20:29 Thomas Koenig
  2021-12-13 22:00 ` Michael Meissner
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Koenig @ 2021-12-13 20:29 UTC (permalink / raw)
  To: fortran, gcc mailing list, Michael Meissner


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.

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

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

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?

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

Regards

	Thomas

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [power-ieee128] Which options for libquadmath / native ieee128
  2021-12-13 20:29 [power-ieee128] Which options for libquadmath / native ieee128 Thomas Koenig
@ 2021-12-13 22:00 ` Michael Meissner
  0 siblings, 0 replies; 2+ messages in thread
From: Michael Meissner @ 2021-12-13 22:00 UTC (permalink / raw)
  To: Thomas Koenig; +Cc: fortran, gcc mailing list, Michael Meissner

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-12-13 22:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-13 20:29 [power-ieee128] Which options for libquadmath / native ieee128 Thomas Koenig
2021-12-13 22:00 ` Michael Meissner

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).