Recently, mingw-w64 has got updated <msxml.h> from Wine which is included
indirectly by <windows.h> if `WIN32_LEAN_AND_MEAN` is not defined. The
`IXMLDOMDocument` class has a member function named `abort()`, which gets
affected by our `abort()` macro in "system.h".

`WIN32_LEAN_AND_MEAN` should, nevertheless, always be defined. This
can exclude 'APIs such as Cryptography, DDE, RPC, Shell, and Windows
Sockets' [1], and speed up compilation of these files a bit.

[1] https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

gcc/

	PR middle-end/108300
	* config/xtensa/xtensa-dynconfig.c: Define `WIN32_LEAN_AND_MEAN`
	before <windows.h>.
	* diagnostic-color.cc: Likewise.
	* plugin.cc: Likewise.
	* prefix.cc: Likewise.

gcc/ada/

	PR middle-end/108300
	* adaint.c: Define `WIN32_LEAN_AND_MEAN` before `#include
	<windows.h>`.
	* cio.c: Likewise.
	* ctrl_c.c: Likewise.
	* expect.c: Likewise.
	* gsocket.h: Likewise.
	* mingw32.h: Likewise.
	* mkdir.c: Likewise.
	* rtfinal.c: Likewise.
	* rtinit.c: Likewise.
	* seh_init.c: Likewise.
	* sysdep.c: Likewise.
	* terminals.c: Likewise.
	* tracebak.c: Likewise.

gcc/jit/

	PR middle-end/108300
	* jit-w32.h: Define `WIN32_LEAN_AND_MEAN` before <windows.h>.

libatomic/

	PR middle-end/108300
	* config/mingw/lock.c: Define `WIN32_LEAN_AND_MEAN` before
	<windows.h>.

libffi/

	PR middle-end/108300
	* src/aarch64/ffi.c: Define `WIN32_LEAN_AND_MEAN` before
	<windows.h>.

libgcc/

	PR middle-end/108300
	* config/i386/enable-execute-stack-mingw32.c: Define
	`WIN32_LEAN_AND_MEAN` before <windows.h>.
	* libgcc2.c: Likewise.
	* unwind-generic.h: Likewise.

libgfortran/

	PR middle-end/108300
	* intrinsics/sleep.c: Define `WIN32_LEAN_AND_MEAN` before
	<windows.h>.

libgomp/

	PR middle-end/108300
	* config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN` before
	<windows.h>.

libiberty/

	PR middle-end/108300
	* make-temp-file.c: Define `WIN32_LEAN_AND_MEAN` before <windows.h>.
	* pex-win32.c: Likewise.

libssp/

	PR middle-end/108300
	* ssp.c: Define `WIN32_LEAN_AND_MEAN` before <windows.h>.

libstdc++-v3/

	PR middle-end/108300
	* src/c++11/system_error.cc: Define `WIN32_LEAN_AND_MEAN` before
	<windows.h>.
	* src/c++11/thread.cc: Likewise.
	* src/c++17/fs_ops.cc: Likewise.
	* src/filesystem/ops.cc: Likewise.

libvtv/

	PR middle-end/108300
	* vtv_malloc.cc: Define `WIN32_LEAN_AND_MEAN` before <windows.h>.
	* vtv_rts.cc: Likewise.
	* vtv_utils.cc: Likewise.

Rotate ChangeLog files for ChangeLogs with yearly cadence.

Since GCC 12, the conversion between the array descriptors formats - the
internal (GFC) and the C binding one (CFI) - moved to the compiler itself
such that the cfi_desc_to_gfc_desc/gfc_desc_to_cfi_desc functions are only
used with older code (GCC 9 to 11).  The newly added checks caused asserts
as older code did not pass the proper values (e.g. real(4) as effective
argument arrived as BT_ASSUME type as the effective type got lost inbetween).

As proposed in the PR, revert to the GCC 11 version - known bugs is better
than some fixes and new issues. Still, GCC 12 is much better in terms of
TS29113 support and should really be used.

This patch uses the current libgomp version of the GCC 11 branch, except
it fixes the GFC version number (which is 0), uses calloc instead of malloc,
and sets the lower bound to 1 instead of keeping it as is for
CFI_attribute_other.

libgfortran/ChangeLog:

	PR libfortran/108056
	* runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc,
	gfc_desc_to_cfi_desc): Mostly revert to GCC 11 version for
	those backward-compatiblity-only functions.

Needed after a recent change.

gcc/ChangeLog:

	* configure: Regenerate.

libatomic/ChangeLog:

	* configure: Regenerate.

libbacktrace/ChangeLog:

	* configure: Regenerate.

libcc1/ChangeLog:

	* configure: Regenerate.

libffi/ChangeLog:

	* configure: Regenerate.

libgfortran/ChangeLog:

	* configure: Regenerate.

libgomp/ChangeLog:

	* configure: Regenerate.

libitm/ChangeLog:

	* configure: Regenerate.

libobjc/ChangeLog:

	* configure: Regenerate.

liboffloadmic/ChangeLog:

	* configure: Regenerate.
	* plugin/configure: Regenerate.

libphobos/ChangeLog:

	* configure: Regenerate.

libquadmath/ChangeLog:

	* configure: Regenerate.

libsanitizer/ChangeLog:

	* configure: Regenerate.

libssp/ChangeLog:

	* configure: Regenerate.

libstdc++-v3/ChangeLog:

	* configure: Regenerate.

libvtv/ChangeLog:

	* configure: Regenerate.

lto-plugin/ChangeLog:

	* configure: Regenerate.

zlib/ChangeLog:

	* configure: Regenerate.

This change adds the configury bits to activate the build of
shared libs on VxWorks ports configured with --enable-shared,
for libraries variants where this is generally supported (rtp,
code model !large - currently not compatible with -fPIC).

Set lt_cv_deplibs_check_method in libtool.m4, so the build of
libraries know how to establish dependencies.  This is useful in
configurations such as aarch64 where proper support of LSE relies
on accurate dependency information between libstdc++ and libgcc_s
to begin with.

Regenerate configure scripts to reflect libtool.m4 change.

2022-10-09  Olivier Hainque  <hainque@adacore.com>

	* libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker
	and friends for rtp !large. Assume the linker has the required
	abilities and set lt_cv_deplibs_check_method.

gcc/
	* config.gcc (*vxworks*): Add t-slibgcc fragment
	if enable_shared.

libgcc/
	* config.host (*vxworks*): When enable_shared, add
	libgcc and crtstuff "shared" fragments for rtp except
	large code model.
	(aarch64*-wrs-vxworks7*): Remove t-slibgcc-libgcc from
	the list of fragments.

2022-10-09  Olivier Hainque  <hainque@adacore.com>

gcc/
	* configure: Regenerate.

libatomic/
	* configure: Regenerate.

libbacktrace/
	* configure: Regenerate.

libcc1/
	* configure: Regenerate.

libffi/
	* configure: Regenerate.

libgfortran/
	* configure: Regenerate.

libgomp/
	* configure: Regenerate.

libitm/
	* configure: Regenerate.

libobjc/
	* configure: Regenerate.

liboffloadmic/
	* configure: Regenerate.

liboffloadmic/
	* plugin/configure: Regenerate.

libphobos/
	* configure: Regenerate.

libquadmath/
	* configure: Regenerate.

libsanitizer/
	* configure: Regenerate.

libssp/
	* configure: Regenerate.

libstdc++-v3/
	* configure: Regenerate.

libvtv/
	* configure: Regenerate.

lto-plugin/
	* configure: Regenerate.

zlib/
	* configure: Regenerate.

It used to cause errors if a thread model other than `posix` was selected,
which looks like a leftover from a7987858.

libgfortran/
	* io/async.h (struct async_unit): Use `__gthread_t` instead
	of `pthread_t`.

Signed-off-by: LIU Hao <lh_mouse@126.com>
Signed-off-by: Jonathan Yong <10walls@gmail.com>

Make sure that calling IEEE_SET_ROUNDING_MODE with RADIX=10 does not
affect the binary rounding mode.

2022-09-21  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

libgfortran/

	* ieee/ieee_arithmetic.F90 (IEEE_SET_ROUNDING_MODE): Handle
	RADIX argument better.

gcc/testsuite/

	* gfortran.dg/ieee/rounding_3.f90: New test.

The symbols were forgotten in the patch that added IEEE_GET_MODES
and IEEE_SET_MODES.

2022-09-21  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

libgfortran/

	* gfortran.map: Add symbols for IEEE_GET_MODES
	and IEEE_SET_MODES.

The IEEE_MODES_TYPE type and the two functions that get and set it
were added in Fortran 2018.  They can be implemented using the already
existing target-specific functions.  A future optimization could, on
some targets, set/get all modes through one or two instructions only,
but that would need a new set of functions in all config/fpu-* files.

2022-09-04  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

libgfortran/

	* ieee/ieee_exceptions.F90: Add IEEE_MODES_TYPE, IEEE_GET_MODES
	and IEEE_SET_MODES.
	* ieee/ieee_arithmetic.F90: Make them public in IEEE_ARITHMETIC
	as well.

gcc/testsuite/

	* gfortran.dg/ieee/modes_1.f90: New test.

Add the new IEEE_AWAY rounding mode. It is unsupported on all known
targets, but could be supported by glibc and AIX as part of the C2x
proposal. Testing for now is minimal.

Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not
support radices other than 2.

2022-08-31  Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>

gcc/fortran/
	* libgfortran.h: Declare GFC_FPE_AWAY.

gcc/testsuite/
	* gfortran.dg/ieee/rounding_2.f90: New test.

libgfortran/
	* ieee/ieee_arithmetic.F90: Add RADIX argument to
	IEEE_SET_ROUNDING_MODE and IEEE_GET_ROUNDING_MODE.
	* config/fpu-387.h: Add IEEE_AWAY mode.
	* config/fpu-aarch64.h: Add IEEE_AWAY mode.
	* config/fpu-aix.h: Add IEEE_AWAY mode.
	* config/fpu-generic.h: Add IEEE_AWAY mode.
	* config/fpu-glibc.h: Add IEEE_AWAY mode.
	* config/fpu-sysv.h: Add IEEE_AWAY mode.

The functions are added to the IEEE_ARITHMETIC module, but
are entirely expanded in the front-end, using GCC built-ins.

2022-08-31  Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>

	PR fortran/95644

gcc/fortran/
	* f95-lang.cc (gfc_init_builtin_functions): Declare FMA
	built-ins.
	* mathbuiltins.def: Declare FMA built-ins.
	* trans-intrinsic.cc (conv_intrinsic_ieee_fma): New function.
	(conv_intrinsic_ieee_signbit): New function.
	(gfc_build_intrinsic_lib_fndecls): Add cases for FMA and
	SIGNBIT.

gcc/testsuite/
	* gfortran.dg/ieee/fma_1.f90: New test.
	* gfortran.dg/ieee/signbit_1.f90: New test.

libgfortran/
	* ieee/ieee_arithmetic.F90: Add IEEE_SIGNBIT and IEEE_FMA.

The following patch expands IEEE_CLASS inline in the FE, using the
__builtin_fpclassify, __builtin_signbit and the new __builtin_issignaling
builtins.

2022-08-26  Jakub Jelinek  <jakub@redhat.com>

	PR fortran/106579
gcc/fortran/
	* f95-lang.cc (gfc_init_builtin_functions): Initialize
	BUILT_IN_FPCLASSIFY.
	* libgfortran.h (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
	IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
	IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
	IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
	IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
	New enum.
	* trans-intrinsic.cc (conv_intrinsic_ieee_class): New function.
	(gfc_conv_ieee_arithmetic_function): Handle ieee_class.
libgfortran/
	* ieee/ieee_helper.c (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
	IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
	IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
	IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
	IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
	Move to gcc/fortran/libgfortran.h.

The following patch makes use of the new __builtin_issignaling,
so it no longer needs the fallback implementation and can use
the builtin even where glibc provides the macro.

2022-08-26  Jakub Jelinek  <jakub@redhat.com>

	PR fortran/105105
	* ieee/ieee_helper.c: Don't include issignaling_fallback.h.
	(CLASSMACRO): Use __builtin_issignaling instead of issignaling.
	* ieee/issignaling_fallback.h: Removed.

The following patch is a revival of the
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg00771.html


patch.  While trunk configured against recent glibc and with linker
--as-needed support doesn't really need to link against -lquadmath
anymore, there are still other targets where libquadmath is still in
use.
As has been discussed, making -static-libgfortran imply statically
linking both libgfortran and libquadmath is undesirable because of
the significant licensing differences between the 2 libraries.
Compared to the 2014 patch, this one doesn't handle -lquadmath
addition in the driver, which to me looks incorrect, libgfortran
configure determines where in libgfortran.spec -lquadmath should
be present if at all and with what it should be wrapped, but
analyzes gfortran -### -static-libgfortran stderr and based on
that figures out what gcc/configure.ac determined.

2022-08-17  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>
	    Jakub Jelinek  <jakub@redhat.com>

	PR fortran/46539
gcc/
	* common.opt (static-libquadmath): New option.
	* gcc.cc (driver_handle_option): Always accept -static-libquadmath.
	* config/darwin.h (LINK_SPEC): Handle -static-libquadmath.
gcc/fortran/
	* lang.opt (static-libquadmath): New option.
	* invoke.texi (-static-libquadmath): Document it.
	* options.cc (gfc_handle_option): Error out if -static-libquadmath
	is passed but we do not support it.
libgfortran/
	* acinclude.m4 (LIBQUADSPEC): From $FC -static-libgfortran -###
	output determine -Bstatic/-Bdynamic, -bstatic/-bdynamic,
	-aarchive_shared/-adefault linker support or Darwin remapping
	of -lgfortran to libgfortran.a%s and use that around or instead
	of -lquadmath in LIBQUADSPEC.
	* configure: Regenerated.

Co-Authored-By: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>

The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
is used (either default through --with-long-double-format=ieee or
when used explicitly).
The problem is that the read/write transfer routines are called with
BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say
it is the IEEE quad real(kind=16) rather than the IBM double double
real(kind=16).  For the floating point input/output we then handle kind
17 specially, but for B/O/Z we just treat the bytes of the floating point
value as binary blob and using 17 in that case results in unexpected
behavior, for write it means we don't estimate right how many chars we'll
need and print ******************** etc. rather than what we should, and
even with explicit size we'd print one further byte than intended.
For read it would even mean overwriting some unrelated byte after the
floating point object.

Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls.

2022-08-01  Jakub Jelinek  <jakub@redhat.com>

	PR libfortran/106079
	* io/transfer.c (formatted_transfer_scalar_read,
	formatted_transfer_scalar_write): For type BT_REAL with kind 17
	change kind to 16 before calling read_radix or write_{b,o,z}.

My patch apparently left some __float128 uses in libgfortran
that could use _Float128 instead, the following patch changes that.

2022-06-29  Jakub Jelinek  <jakub@redhat.com>

	* mk-kinds-h.sh: Change __float128 to _Float128 in a comment.
	* acinclude.m4 (LIBGFOR_CHECK_MATH_IEEE128): Use _Float128 instead of
	__float128.
	* libgfortran.h (isnan): Change __float128 to _Float128 in a comment.
	(__acoshieee128, __acosieee128, __asinhieee128, __asinieee128,
	__atan2ieee128, __atanhieee128, __atanieee128, __copysignieee128,
	__coshieee128, __cosieee128, __erfcieee128, __erfieee128,
	__expieee128, __fabsieee128, __fmaieee128, __fmodieee128, __jnieee128,
	__log10ieee128, __logieee128, __powieee128, __sinhieee128,
	__sinieee128, __sqrtieee128, __tanhieee128, __tanieee128,
	__ynieee128, __strtoieee128): Use _Float128 instead of __float128.
	* configure: Regenerated.

My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds.  While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported and long double isn't IEEE quad precision.
Which is targets that support __float128 type which we have been testing
for before - _Float128 is supported on those targets and on targets where
long double is IEEE quad precision.

So, the following patch restores check for whether __float128 is supported
into the LIBGFOR_CHECK_FLOAT128 check which determines whether
HAVE_FLOAT128 is defined or whether to use libquadmath, so that e.g. on
aarch64 where long double is IEEE quad we don't do that.

2022-06-29  Jakub Jelinek  <jakub@redhat.com>

	PR bootstrap/106137
	* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Adjust comment.
	Also test for __float128.
	(HAVE_FLOAT128): Adjust description.
	* config.h.in: Regenerated.
	* configure: Regenerated.

As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid libquadmath for Fortran purposes on these architectures,
replace *q math/complex APIs, strtof128 instead of strtoflt128 and,
while strfromf128 unfortunately isn't a perfect replacement to
quadmath_snprintf, it can be made to work.

The advantage of this is that when configured against such glibcs
(2.26 is now almost 5 years old), we can avoid linking against an extra shared
library and the math support in glibc is maintained better than libquadmath.

We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
instead of *q) and library change.

The above mentioned problem with strfromf128 is that the strfrom* functions
are severely restricted versions of snprintf.  In libgfortran, we handle
!isfinite differently and just use snprintf/quadmath_snprintf for
%+-#.*{L,Q}{f,e} printing.
strfrom* doesn't allow +, -, # modifiers and it only supports .34 or
similar precision, not .* .  The L/Q etc. letters are omitted.
The + is there to force + sign at the start if it is positive.
Workaround in the patch is to add the + at the start manually for
!signbit (val).
The - (left alignment instead of right) I don't understand why we need it,
when minimum field width isn't specified (for strfrom* can't be specified),
no padding is ever added anywhere I believe.
The # is to force adding . - workaround is to search for first . or e or '\0'
character, if it is '\0', just append ., if it is e, insert . before e and
memmove the rest (which is just a few bytes, e, +/- and at most a few digits)
one byte later.
The .* case is handled by creating the format string for strfrom* by
snprintf into a temporary buffer.

As requested, this patch also switches from using __float128 type in
libgfortran to _Float128 which is equivalent on all arches that support
__float128.

The change is done in a backwards compatible change, when GCC is configured
against glibc 2.26 or newer, libgfortran.so.5 itself doesn't link against
-lquadmath nor uses any libquadmath APIs, libgfortran.a doesn't use any
libquadmath APIs either.  User programs and libraries when being linked
by gfortran driver are linked against -lgfortran and -lquadmath, but
the latter only in the --as-needed linker mode, which means it needs
to be around during linking and will be linked in if there are any
calls to math/complex functions with real(kind=16) or complex(kind=16)
in compilation units compiled by older versions of gcc, but if either
user code doesn't call those math/complex functions for the largest
supported kind, or the code is recompiled by gcc with this change in,
libquadmath won't be linked in.

2022-06-28  Jakub Jelinek  <jakub@redhat.com>

gcc/fortran/
	* gfortran.h (gfc_real_info): Add use_iec_60559 bitfield.
	* trans-types.h (gfc_real16_use_iec_60559): Declare.
	* trans-types.cc (gfc_real16_use_iec_60559): Define.
	(gfc_init_kinds): When building powerpc64le-linux libgfortran
	on glibc 2.26 to 2.31, set gfc_real16_use_iec_60559 and
	use_iec_60559.
	(gfc_build_real_type): Set gfc_real16_use_iec_60559 and use_iec_60559
	on glibc 2.26 or later.
	* trans-intrinsic.cc (gfc_build_intrinsic_lib_fndecls): Adjust
	comment.  Handle gfc_real16_use_iec_60559.
	(gfc_get_intrinsic_lib_fndecl): Handle use_iec_60559.
libgfortran/
	* configure.ac: Check for strtof128 and strfromf128.
	Check for math and complex *f128 functions.  Set
	have_iec_60559_libc_support to yes if *f128 support is around, for
	--enable-libquadmath-support default to "default" rather than yes if
	have_iec_60559_libc_support is yes.
	* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Test
	_Float128/_Complex _Float128 rather than __float128 and
	_Complex float __attribute__((mode(TC))).  If libquadmath support
	is defaulted and have_iec_60559_libc_support is yes, define and subst
	USE_IEC_60559.  Remove unused LIBGFOR_BUILD_QUAD conditional.
	* Makefile.am (kinds.h): Pass @USE_IEC_60559@ as an extra
	mk-kinds-h.sh argument.
	* mk-kinds-h.sh: Accept 4th use_iec_60559 argument.  Use
	_Float128/_Complex _Float128 types instead of __float128 and
	_Complex float __attribute__((mode(TC))), and if use_iec_60559 is yes,
	use f128 suffix instead of q and define GFC_REAL_16_USE_IEC_60559.
	* kinds-override.h: Use _Float128/_Complex _Float128 types instead of
	__float128 and _Complex float __attribute__((mode(TC))), if
	USE_IEC_60559 is defined, use f128 suffixes instead of q and
	define GFC_REAL_17_USE_IEC_60559.
	* libgfortran.h: Don't include quadmath_weak.h if USE_IEC_60559 is
	defined.
	(GFC_REAL_16_INFINITY, GFC_REAL_16_QUIET_NAN): Define
	for GFC_REAL_16_USE_IEC_60559 differently.
	* caf/single.c (convert_type): Use _Float128/_Complex _Float128
	instead of __float128 and _Complex float __attribute__((mode(TC))).
	For HAVE_GFC_REAL_10 when HAVE_GFC_REAL_16 isn't defined use
	_Complex long double instead of long double.
	* ieee/issignaling_fallback.h (ieee854_float128_shape_type): Use
	_Float128 instead of __float128.
	(__issignalingf128): Change argument type to _Float128.
	(issignaling): Use _Float128 instead of __float128 in _Generic.
	* intrinsics/cshift0.c (cshift0): Use _Float128 instead of __float128
	in a comment.  Fix a comment typo, logn double -> long double.
	* intrinsics/erfc_scaled.c (_THRESH, _M_2_SQRTPI, _INF, _ERFC, _EXP):
	Use different definitions if GFC_REAL_16_USE_IEC_60559.
	(_THRESH, _M_2_SQRTPI): Use GFC_REAL_17_LITERAL macro.
	(_ERFC, _EXP): Use different definitions if GFC_REAL_17_USE_IEC_60559.
	* intrinsics/spread_generic.c (spread, spread_scalar): Use _Float128
	instead of __float128 in a comment.  Fix a comment typo,
	logn double -> long double.
	* intrinsics/trigd.c (ENABLE_SIND, ENABLE_COSD, ENABLE_TAND): Handle
	GFC_REAL_16_USE_IEC_60559.
	* intrinsics/pack_generic.c (pack): Use _Float128 instead of
	__float128 in a comment.  Fix a comment typo, logn double ->
	long double.
	* intrinsics/unpack_generic.c (unpack1, unpack0): Likewise.
	* runtime/in_pack_generic.c (internal_pack): Likewise.
	* runtime/in_unpack_generic.c (internal_unpack): Likewise.
	* io/read.c (convert_real, convert_infnan): Handle
	GFC_REAL_16_USE_IEC_60559 and GFC_REAL_17_USE_IEC_60559.
	* io/transfer128.c (tmp1, tmp2): Don't define if libquadmath
	isn't needed.
	* io/write_float.def (gfor_strfromf128): New function.
	(DTOA2Q, FDTOA2Q): Define differently if
	GFC_REAL_16_USE_IEC_60559 or GFC_REAL_17_USE_IEC_60559.
	* m4/mtype.m4: Use different suffix if GFC_REAL_16_USE_IEC_60559
	or GFC_REAL_17_USE_IEC_60559.
	* config.h.in: Regenerated.
	* configure: Regenerated.
	* Makefile.in: Regenerated.
	* generated/bessel_r16.c: Regenerated.
	* generated/bessel_r17.c: Regenerated.
	* generated/norm2_r16.c: Regenerated.
	* generated/norm2_r17.c: Regenerated.

libgfortran/ChangeLog:

	PR libfortran/104233
	* ieee/issignaling_fallback.h: Check GFC_REAL_16_IS_FLOAT128
	instead of __FLT128_IS_IEC_60559__.

libgfortran/ChangeLog:

	* ieee/issignaling_fallback.h: Fix GCC-specific preprocessor
	macros.

On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series.
> For targets with IEEE support but without the issignaling macro in libc
> (i.e., everywhere except glibc), this allows us to provide a fallback
> implementation.

This doesn't seem to handle the powerpc* IBM double double long double.

__LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from
an IEEE754 type, but it has signaling NaNs - as can be seen in glibc
libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c
the type is a pair of doubles and whether it is a sNaN or qNaN is determined
by whether the first double is a sNaN or qNaN.

2022-01-25  Jakub Jelinek  <jakub@redhat.com>

	* ieee/issignaling_fallback.h (__issignalingl): Define for
	IBM extended long double are returning __issignaling on the
	first double.

libgfortran/ChangeLog:

	* ieee/issignaling_fallback.h: fix preprocessor condition.

For targets with IEEE support but without the issignaling macro in libc
(currently, everywhere except glibc), this allows us to provide a fallback
implementation. In order to keep the code in ieee_helper.c relatively
readable, I've put that new implementation in a separate file,
issignaling_fallback.h.

libgfortran/ChangeLog:

	* ieee/issignaling_fallback.h: New file.
	* ieee/ieee_helper.c: Include issignaling_fallback.h when target
	does not define issignaling macro.

gcc/testsuite/ChangeLog:

	* gfortran.dg/ieee/signaling_1.f90: Do not require issignaling.
	* gfortran.dg/ieee/signaling_2.f90: Add comment.
	* gfortran.dg/ieee/signaling_3.f90: New test.