aboutsummaryrefslogtreecommitdiff
path: root/libgfortran
AgeCommit message (Collapse)AuthorFilesLines
2022-09-22Daily bump.GCC Administrator1-0/+10
2022-09-21Fortran: handle RADIX kind in IEEE_SET_ROUNDING_MODEFrancois-Xavier Coudert1-3/+9
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.
2022-09-21Fortran: add symbols in version map for IEEE_GET_MODES and IEEE_SET_MODESFrancois-Xavier Coudert1-0/+6
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.
2022-09-20Daily bump.GCC Administrator1-0/+18
2022-09-19Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODESFrancois-Xavier Coudert2-1/+65
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.
2022-09-19Fortran: F2018 rounding modes changesFrancois-Xavier Coudert7-12/+67
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.
2022-09-11Daily bump.GCC Administrator1-0/+5
2022-09-10fortran: Add IEEE_SIGNBIT and IEEE_FMA functionsFrancois-Xavier Coudert1-0/+66
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.
2022-08-27Daily bump.GCC Administrator1-0/+17
2022-08-26fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]Jakub Jelinek1-20/+0
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.
2022-08-26libgfortran: Use __builtin_issignaling in libgfortran [PR105105]Jakub Jelinek2-259/+1
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.
2022-08-18Daily bump.GCC Administrator1-0/+11
2022-08-17fortran: Add -static-libquadmath support [PR46539]Jakub Jelinek2-6/+47
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>
2022-08-02Daily bump.GCC Administrator1-0/+7
2022-08-01libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble ↵Jakub Jelinek1-0/+24
[PR106079] 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}.
2022-06-30Daily bump.GCC Administrator1-0/+24
2022-06-29libgfortran: Switch some more __float128 uses to _Float128Jakub Jelinek4-75/+75
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.
2022-06-29libgfortran: Fix up LIBGFOR_CHECK_FLOAT128 [PR106137]Jakub Jelinek3-6/+24
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.
2022-06-29Daily bump.GCC Administrator1-0/+68
2022-06-28fortran, libgfortran: Avoid using libquadmath for glibc 2.26+Jakub Jelinek27-128/+3547
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.
2022-01-27Daily bump.GCC Administrator1-0/+6
2022-01-26Fortran: fix bootstrap on SPARC/SolarisFrancois-Xavier Coudert1-3/+3
libgfortran/ChangeLog: PR libfortran/104233 * ieee/issignaling_fallback.h: Check GFC_REAL_16_IS_FLOAT128 instead of __FLT128_IS_IEC_60559__.
2022-01-26Daily bump.GCC Administrator1-0/+15
2022-01-26Fortran: fix issignaling() implementationFrancois-Xavier Coudert1-6/+6
libgfortran/ChangeLog: * ieee/issignaling_fallback.h: Fix GCC-specific preprocessor macros.
2022-01-25libfortran: Provide fallback __issignalingl for IBM extended long doubleJakub Jelinek1-0/+13
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.
2022-01-25Fortran: fix preprocessor conditionFrancois-Xavier Coudert1-1/+1
libgfortran/ChangeLog: * ieee/issignaling_fallback.h: fix preprocessor condition.
2022-01-25Daily bump.GCC Administrator1-0/+6
2022-01-24Fortran: provide a fallback implementation of issignalingFrancois-Xavier Coudert2-4/+241
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.
2022-01-18Daily bump.GCC Administrator1-0/+10
2022-01-17Fortran: remove new files introduced by mistakeFrancois-Xavier Coudert1-238/+0
These two files were introduced by mistake in 86e3b476d5defaa79c94d40b76cbeec21cd02e5f gcc/testsuite/ChangeLog: * gfortran.dg/ieee/signaling_3.f90: Remove file. libgfortran/ChangeLog: * ieee/issignaling_fallback.h: Remove file.
2022-01-17Allow for multiple defaults in endianness and r16 in GFORTRAN_CONVERT_UNIT.Thomas Koenig1-55/+56
With this patch, it is possible to specify multiple defaults inthe GFORTRAN_CONVERT_UNIT environment variable so that, for example, R16_IEEE and BIG_ENDIAN can be specified together. libgfortran/ChangeLog: * runtime/environ.c: Allow for multiple default values so that separate default specifications for IBM long double format and endianness are possible.
2022-01-17Daily bump.GCC Administrator1-0/+13
2022-01-17Fortran: xfail signaling NaN testcases on x87Francois-Xavier Coudert1-0/+238
The ABI for x87 and x86-32 is not suitable for passing around signaling NaNs in the way IEEE expects. See for example discussion in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 gcc/testsuite/ChangeLog: * gfortran.dg/ieee/signaling_1.f90: xfail on x87. * gfortran.dg/ieee/signaling_2.f90: xfail on x87.
2022-01-16Fortran: allow IEEE_VALUE to correctly return signaling NaNsFrancois-Xavier Coudert3-248/+117
I moved the library implementation of IEEE_VALUE in libgfortran from Fortran to C code, which gives us access to GCC's built-ins for NaN generation (both quiet and signalling). It will be perform better than the current Fortran implementation. libgfortran/ChangeLog: PR fortran/82207 * mk-kinds-h.sh: Add values for TINY. * ieee/ieee_arithmetic.F90: Call C helper functions for IEEE_VALUE. * ieee/ieee_helper.c: New functions ieee_value_helper_N for each floating-point type. gcc/testsuite/ChangeLog: PR fortran/82207 * gfortran.dg/ieee/ieee_10.f90: Do not create signaling NaNs. * gfortran.dg/ieee/signaling_2.f90: New test. * gfortran.dg/ieee/signaling_2_c.c: New file.
2022-01-15Daily bump.GCC Administrator1-0/+7
2022-01-14libgfortran: Partly revert my r12-6498 change to fix Solaris build [PR104006]Jakub Jelinek2-4/+4
In r12-6498 I've added $(version_dep) to BUILT_SOURCES, previously version_dep on Linux used to be a file in $(srcdir), but with my changes it is a generated file in the object directory (preprocessed version of the $(srcdir) file) and I thought generated files belong to BUILT_SOURCES so that they are cleaned up etc. For Linux that is fine, but it broke parallel builds on Solaris. BUILT_SOURCES is a special variable for automake where automake ensures that for make all, make check and make install all those $(BUILT_SOURCES) are generated before actually starting building in parallel the various object files. That way we can avoid hacks like: $(patsubst %.F90,%.lo,$(notdir $(filter %.F90,$(prereq_SRC)))): kinds.inc c99_protos.inc $(patsubst %.c,%.lo,$(notdir $(filter %.c,$(prereq_SRC)))): kinds.h $(patsubst %.f90,%.lo,selected_real_kind.f90): selected_real_kind.inc $(patsubst %.f90,%.lo,selected_int_kind.f90): selected_int_kind.inc $(patsubst %.F90,%.lo,ieee_exceptions.F90): fpu-target.inc $(patsubst %.F90,%.lo,ieee_arithmetic.F90): fpu-target.inc ieee_exceptions.lo $(patsubst %.c,%.lo,fpu.c): fpu-target.h which makes those dependencies explicit but hides it from automake, so that it doesn't throw away its rules for those object files. On Solaris, $(version_dep) contains gfortran.ver and gfortran.ver-sun. gfortran.ver is like on Linux, it can be in $(BUILT_SOURCES), but unfortunately gfortran.ver-sun depends on all the object files being compiled already, so if gfortran.ver-sun appears in $(BUILT_SOURCES), the BUILT_SOURCES function of ensuring the generated files are generated before building object files is gone, almost everything is built before all-am is entered and there are no explicit dependencies that e.g. *.F90 files depend on kinds.inc etc. So, this change reverts that mistake and instead adds $(version_dep) to what is removed during make clean (clean-local in particular). 2022-01-14 Jakub Jelinek <jakub@redhat.com> PR libfortran/104006 * Makefile.am (BUILT_SOURCES): Don't include $(version_dep). (clean-local): Remove $(version_dep). * Makefile.in: Regenerated.
2022-01-14Daily bump.GCC Administrator1-0/+7
2022-01-13libgfortran: Fix Solaris version file creation [PR104006]Jakub Jelinek2-3/+2
I forgot to change the gfortran.map-sun goal to gfortran.ver-sun when changing other spots for the preprocessed version file. 2022-01-13 Jakub Jelinek <jakub@redhat.com> PR libfortran/104006 * Makefile.am (gfortran.map-sun): Rename target to ... (gfortran.ver-sun): ... this. * Makefile.in: Regenerated.
2022-01-13Daily bump.GCC Administrator1-0/+5
2022-01-12libgfortran: Fix build on non-glibc targetsJakub Jelinek1-1/+3
When the __GLIBC_PREREQ macro isn't defined, the #if ... && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32) directive has invalid syntax - the __GLIBC_PREREQ in there evaluates to 0 and is followed by (2, 32). 2022-01-12 Jakub Jelinek <jakub@redhat.com> * libgfortran.h (POWER_IEEE128): Use __GLIBC_PREREQ in a separate #if directive inside of #if ... && defined __GLIBC_PREREQ.
2022-01-12Daily bump.GCC Administrator1-0/+300
2022-01-11power-ieee128: Fix up byte-swapping for IBM extended real(kind=16)Jakub Jelinek1-2/+36
Here is a patch to fix up the ppc64be vs. ppc64le byteswapping of IBM extended real(kind=16) and complex(kind=16). Similarly to the BT_COMPLEX case it halves size and doubles nelems for the bswap_array calls. Of course for r16_ibm and r16_ieee conversions one needs to make sure it is only done when the on file data is in that format and not in IEEE quad. 2022-01-11 Jakub Jelinek <jakub@redhat.com> * io/transfer.c (unformatted_read, unformatted_write): When byteswapping IBM extended real(kind=16), handle it as byteswapping two real(kind=8) values.
2022-01-11Handle R16 conversion for POWER in the environment variables.Thomas Koenig1-1/+48
This patch handles the environment variables for the REAL(KIND=16) variables like for the little/big-endian routines, so users without who have no access to the source or are unwilling to recompile can use this. Syntax is, for example GFORTRAN_CONVERT_UNIT="r16_ieee:10;little_endian:10" ./a.out libgfortran/ChangeLog: * runtime/environ.c (R16_IEEE): New macro. (R16_IBM): New macro. (next_token): Handle IBM R16 conversion cases. (push_token): Likewise. (mark_single): Likewise. (do_parse): Likewise, initialize endian.
2022-01-11Implement CONVERT specifier for OPEN.Thomas Koenig5-12/+174
This patch, based on Jakub's work, implements the CONVERT specifier for the power-ieee128 brach. It allows specifying the conversion as r16_ieee,big_endian and the other way around, based on a table. Setting the conversion via environment variable and via program option does not yet work. gcc/ChangeLog: * flag-types.h (enum gfc_convert): Add flags for conversion. gcc/fortran/ChangeLog: * libgfortran.h (unit_convert): Add flags. libgfortran/ChangeLog: * Makefile.in: Regenerate. * io/file_pos.c (unformatted_backspace): Mask off R16 parts for convert. * io/inquire.c (inquire_via_unit): Add cases for R16 parts. * io/open.c (st_open): Add cases for R16 conversion. * io/transfer.c (unformatted_read): Adjust for R16 conversions. (unformatted_write): Likewise. (us_read): Mask of R16 bits. (data_transfer_init): Likewiese. (write_us_marker): Likewise.
2022-01-11libgfortran: Make sure glibc < 2.32 built powerpc64le-linux libgfortran ↵Jakub Jelinek2-6/+6
doesn't use __*ieee128 APIs I've just tried to build libgfortran on an old glibc system (gcc112.fsffrance.org) and unfortunately we still have work to do: [jakub@gcc2-power8 obj38]$ LD_PRELOAD=/home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 /bin/true [jakub@gcc2-power8 obj38]$ LD_BIND_NOW=1 LD_PRELOAD=/home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 /bin/true /bin/true: symbol lookup error: /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0: undefined symbol: __atan2ieee128 While we do use some libquadmath APIs: readelf -Wr /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 | grep QUADMATH 0000000000251268 000005e400000026 R_PPC64_ADDR64 0000000000000000 quadmath_snprintf@QUADMATH_1.0 + 0 0000000000251270 0000030600000026 R_PPC64_ADDR64 0000000000000000 strtoflt128@QUADMATH_1.0 + 0 00000000002502e0 0000011600000015 R_PPC64_JMP_SLOT 0000000000000000 ynq@QUADMATH_1.0 + 0 0000000000250390 0000016000000015 R_PPC64_JMP_SLOT 0000000000000000 sqrtq@QUADMATH_1.0 + 0 0000000000250508 000001fa00000015 R_PPC64_JMP_SLOT 0000000000000000 fmaq@QUADMATH_1.0 + 0 0000000000250530 0000021200000015 R_PPC64_JMP_SLOT 0000000000000000 fabsq@QUADMATH_1.0 + 0 0000000000250760 0000030600000015 R_PPC64_JMP_SLOT 0000000000000000 strtoflt128@QUADMATH_1.0 + 0 0000000000250990 000003df00000015 R_PPC64_JMP_SLOT 0000000000000000 cosq@QUADMATH_1.0 + 0 00000000002509f0 0000040a00000015 R_PPC64_JMP_SLOT 0000000000000000 expq@QUADMATH_1.0 + 0 0000000000250a88 0000045100000015 R_PPC64_JMP_SLOT 0000000000000000 erfcq@QUADMATH_1.0 + 0 0000000000250a98 0000045e00000015 R_PPC64_JMP_SLOT 0000000000000000 jnq@QUADMATH_1.0 + 0 0000000000250ac8 0000047e00000015 R_PPC64_JMP_SLOT 0000000000000000 sinq@QUADMATH_1.0 + 0 0000000000250e38 000005db00000015 R_PPC64_JMP_SLOT 0000000000000000 fmodq@QUADMATH_1.0 + 0 0000000000250e48 000005e000000015 R_PPC64_JMP_SLOT 0000000000000000 tanq@QUADMATH_1.0 + 0 0000000000250e58 000005e400000015 R_PPC64_JMP_SLOT 0000000000000000 quadmath_snprintf@QUADMATH_1.0 + 0 0000000000250f20 0000062900000015 R_PPC64_JMP_SLOT 0000000000000000 copysignq@QUADMATH_1.0 + 0 we don't do it consistently: readelf -Wr /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0 | grep ieee128 0000000000250310 0000012800000015 R_PPC64_JMP_SLOT 0000000000000000 __atan2ieee128 + 0 0000000000250340 0000014200000015 R_PPC64_JMP_SLOT 0000000000000000 __clogieee128 + 0 0000000000250438 000001a300000015 R_PPC64_JMP_SLOT 0000000000000000 __acoshieee128 + 0 00000000002504b8 000001cc00000015 R_PPC64_JMP_SLOT 0000000000000000 __csinieee128 + 0 0000000000250500 000001f300000015 R_PPC64_JMP_SLOT 0000000000000000 __sinhieee128 + 0 0000000000250570 0000022a00000015 R_PPC64_JMP_SLOT 0000000000000000 __asinieee128 + 0 0000000000250580 0000022d00000015 R_PPC64_JMP_SLOT 0000000000000000 __roundieee128 + 0 00000000002505a0 0000023e00000015 R_PPC64_JMP_SLOT 0000000000000000 __logieee128 + 0 00000000002505c8 0000024900000015 R_PPC64_JMP_SLOT 0000000000000000 __tanieee128 + 0 0000000000250630 0000027500000015 R_PPC64_JMP_SLOT 0000000000000000 __ccosieee128 + 0 0000000000250670 0000028a00000015 R_PPC64_JMP_SLOT 0000000000000000 __log10ieee128 + 0 00000000002506c8 000002bd00000015 R_PPC64_JMP_SLOT 0000000000000000 __cexpieee128 + 0 00000000002506d8 000002c800000015 R_PPC64_JMP_SLOT 0000000000000000 __coshieee128 + 0 00000000002509b0 000003ef00000015 R_PPC64_JMP_SLOT 0000000000000000 __truncieee128 + 0 0000000000250af8 000004a600000015 R_PPC64_JMP_SLOT 0000000000000000 __expieee128 + 0 0000000000250b50 000004c600000015 R_PPC64_JMP_SLOT 0000000000000000 __fmodieee128 + 0 0000000000250bb0 000004e700000015 R_PPC64_JMP_SLOT 0000000000000000 __tanhieee128 + 0 0000000000250c38 0000051300000015 R_PPC64_JMP_SLOT 0000000000000000 __acosieee128 + 0 0000000000250ce0 0000055400000015 R_PPC64_JMP_SLOT 0000000000000000 __sinieee128 + 0 0000000000250d60 0000057e00000015 R_PPC64_JMP_SLOT 0000000000000000 __atanieee128 + 0 0000000000250dd8 000005b100000015 R_PPC64_JMP_SLOT 0000000000000000 __sqrtieee128 + 0 0000000000250e98 0000060200000015 R_PPC64_JMP_SLOT 0000000000000000 __cosieee128 + 0 0000000000250eb0 0000060a00000015 R_PPC64_JMP_SLOT 0000000000000000 __atanhieee128 + 0 0000000000250ef0 0000062000000015 R_PPC64_JMP_SLOT 0000000000000000 __asinhieee128 + 0 0000000000250fd8 0000067f00000015 R_PPC64_JMP_SLOT 0000000000000000 __csqrtieee128 + 0 0000000000251038 000006ad00000015 R_PPC64_JMP_SLOT 0000000000000000 __cabsieee128 + 0 All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc. It seems all these come from f951 compiled sources. For user code, I think the agreement was if you want to use successfully -mabi=ieeelongdouble, you need glibc 2.32 or later, which is why the Fortran FE doesn't conditionalize on whether glibc 2.32 is available or not and just emits __WHATEVERieee128 entrypoints. But for Fortran compiled sources in libgfortran, we need to use __WHATEVERieee128 only if glibc 2.32 or later and WHATEVERq (from libquadmath) otherwise. The following patch implements that, adds -fbuilding-libgfortran option similar to e.g. -fbuilding-libgcc used when building libgcc and if that option is set and the TARGET_GLIBC_{MAJOR,MINOR} macros indicate no glibc or glibc older than 2.32, it will use the libquadmath APIs rather than glibc 2.32 APIs. 2022-01-07 Jakub Jelinek <jakub@redhat.com> gcc/fortran/ * trans-types.c (gfc_init_kinds): When setting abi_kind to 17, if not targetting glibc 2.32 or later and -fbuilding-libgfortran, set gfc_real16_is_float128 and c_float128 in gfc_real_kinds. (gfc_build_real_type): Don't set c_long_double if c_float128 is already set. * trans-intrinsic.c (builtin_decl_for_precision): Don't use long_double_built_in if gfc_real16_is_float128 and long_double_type_node == gfc_float128_type_node. * lang.opt (fbuilding-libgfortran): New undocumented option. libgfortran/ * Makefile.am (AM_FCFLAGS): Add -fbuilding-libgfortran after -fallow-leading-underscore. * Makefile.in: Regenerated.
2022-01-11libgfortran: Avoid using libquadmath APIs on powerpc64le on glibc 2.32+Jakub Jelinek3-0/+18
On a glibc 2.32+ build, we still use some libquadmath APIs when we shouldn't: readelf -Wr /home/jakub/gcc/obj/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5 | grep QUADMATH 00000000002502c8 0000002600000015 R_PPC64_JMP_SLOT 0000000000000000 fmaq@QUADMATH_1.0 + 0 00000000002505f8 0000006700000015 R_PPC64_JMP_SLOT 0000000000000000 tanq@QUADMATH_1.0 + 0 0000000000250930 0000009b00000015 R_PPC64_JMP_SLOT 0000000000000000 fabsq@QUADMATH_1.0 + 0 0000000000250940 0000009d00000015 R_PPC64_JMP_SLOT 0000000000000000 sinq@QUADMATH_1.0 + 0 0000000000250c98 000000cf00000015 R_PPC64_JMP_SLOT 0000000000000000 copysignq@QUADMATH_1.0 + 0 0000000000251038 0000010700000015 R_PPC64_JMP_SLOT 0000000000000000 cosq@QUADMATH_1.0 + 0 0000000000251068 0000010a00000015 R_PPC64_JMP_SLOT 0000000000000000 fmodq@QUADMATH_1.0 + 0 These should use __fmaieee128, __tanieee128 etc. instead. 2022-01-07 Jakub Jelinek <jakub@redhat.com> * libgfortran.h (__copysignieee128, __fmaieee128, __fmodieee128): Declare. * intrinsics/trigd.c (COPYSIGN, FMOD, FABS, FMA, SIN, COS, TAN): If POWER_IEEE128 is defined, define these for kind 17 include. * intrinsics/trigd_lib.inc (COPYSIGN, FMOD, FABS, FMA, SIN, COS, TAN): Don't define if COPYSIGN is already defined.
2022-01-11fortran, libgfortran: Add remaining missing *_r17 symbolsJakub Jelinek4-40/+250
Following patch adds remaining missing *_r17 entrypoints, so that we have 91 *_r16 and 91 *_r17 entrypoints (and 24 *_c16 and 24 *_c17). This fixes: FAIL: gfortran.dg/dec_math.f90 -O0 execution test FAIL: gfortran.dg/dec_math.f90 -O1 execution test FAIL: gfortran.dg/dec_math.f90 -O2 execution test FAIL: gfortran.dg/dec_math.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/dec_math.f90 -O3 -g execution test FAIL: gfortran.dg/dec_math.f90 -Os execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O0 execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O1 execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O2 execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/dec_math_1.f90 -Os execution test 2022-01-04 Jakub Jelinek <jakub@redhat.com> gcc/fortran/ * trans-intrinsic.c (gfc_get_intrinsic_lib_fndecl): Use gfc_type_abi_kind. libgfortran/ * libgfortran.h (GFC_REAL_17_INFINITY, GFC_REAL_17_QUIET_NAN): Define. (__erfcieee128): Declare. * intrinsics/trigd.c (_gfortran_sind_r17, _gfortran_cosd_r17, _gfortran_tand_r17): Define for HAVE_GFC_REAL_17. * intrinsics/random.c (random_r17, arandom_r17, rnumber_17): Define. * intrinsics/erfc_scaled.c (ERFC_SCALED): Define. (erfc_scaled_r16): Use ERFC_SCALED macro. (erfc_scaled_r17): Define.
2022-01-11fortran, libgfortran: Assorted -mabi=ieeelongdouble I/O fixesJakub Jelinek1-0/+1
Another patch, this fixes: FAIL: gfortran.dg/intrinsic_spread_2.f90 -O0 execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O1 execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O2 execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -O3 -g execution test FAIL: gfortran.dg/intrinsic_spread_2.f90 -Os execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O0 execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O1 execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O2 execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -O3 -g execution test FAIL: gfortran.dg/intrinsic_unpack_2.f90 -Os execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O0 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O1 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O2 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -Os execution test FAIL: gfortran.dg/quad_2.f90 -O0 execution test FAIL: gfortran.dg/quad_2.f90 -O1 execution test FAIL: gfortran.dg/quad_2.f90 -O2 execution test FAIL: gfortran.dg/quad_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/quad_2.f90 -O3 -g execution test FAIL: gfortran.dg/quad_2.f90 -Os execution test 2022-01-04 Jakub Jelinek <jakub@redhat.com> gcc/fortran/ * trans-io.c (transfer_array_desc): Pass abi kind instead of kind to libgfortran. libgfortran/ * io/read.c (convert_real): Add missing break; for the HAVE_GFC_REAL_17 case.
2022-01-11libgfortran: -mabi=ieeelongdouble I/O fixJakub Jelinek1-2/+6
The following patch fixes: FAIL: gfortran.dg/fmt_en.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_rd.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_rn.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_ru.f90 -Os output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_en_rz.f90 -Os output pattern test FAIL: gfortran.dg/fmt_g0_7.f08 -O0 execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O1 execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O2 execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/fmt_g0_7.f08 -O3 -g execution test FAIL: gfortran.dg/fmt_g0_7.f08 -Os execution test FAIL: gfortran.dg/fmt_pf.f90 -O0 output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O1 output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O2 output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions output pattern test FAIL: gfortran.dg/fmt_pf.f90 -O3 -g output pattern test FAIL: gfortran.dg/fmt_pf.f90 -Os output pattern test FAIL: gfortran.dg/large_real_kind_1.f90 -O0 execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O1 execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O2 execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_1.f90 -Os execution test 2022-01-04 Jakub Jelinek <jakub@redhat.com> * io/write_float.def (CALCULATE_EXP): If HAVE_GFC_REAL_17, also use CALCULATE_EXP(17). (determine_en_precision): Use 17 instead of 16 as first EN_PREC argument for kind 17. (get_float_string): Use 17 instead of 16 as first FORMAT_FLOAT argument for kind 17.
2022-01-11fortran, libgfortran: -mabi=ieeelongdouble I/OJakub Jelinek10-46/+193
The following patch adds the compiler and library side of -mabi=ieeelongdouble I/O support. 2022-01-04 Jakub Jelinek <jakub@redhat.com> gcc/fortran/ * trans-io.c (transfer_namelist_element): Use gfc_type_abi_kind, formatting fixes. (transfer_expr): Use gfc_type_abi_kind, use *REAL128* APIs even for abi_kind == 17. libgfortran/ * libgfortran.h (__acoshieee128, __acosieee128, __asinhieee128, __asinieee128, __atan2ieee128, __atanhieee128, __atanieee128, __coshieee128, __cosieee128, __erfieee128, __expieee128, __fabsieee128, __jnieee128, __log10ieee128, __logieee128, __powieee128, __sinhieee128, __sinieee128, __sqrtieee128, __tanhieee128, __tanieee128, __ynieee128): Formatting fixes. (__strtoieee128, __snprintfieee128): Declare. * io/io.h (default_width_for_float, default_precision_for_float): Handle kind == 17. * io/size_from_kind.c (size_from_real_kind, size_from_complex_kind): Likewise. * io/read.c (set_integer, si_max, convert_real, convert_infnan, read_f): Likewise. * io/write.c (extract_uint, size_from_kind, set_fnode_default): Likewise. * io/write_float.def (DTOA2Q, FDTOA2Q): Define for HAVE_GFC_REAL_17. (determine_en_precision, get_float_string): Handle kind == 17. * io/transfer128.c: Use also for HAVE_GFC_REAL_17, but don't drag in libquadmath if POWER_IEEE128. * Makefile.am (comma, PREPROCESS): New variables. (gfortran.ver): New goal. (version_arg, version_dep): Use gfortran.ver instead of $(srcdir)/gfortran.map. (gfortran.map-sun): Depend on and use gfortran.ver instead of $(srcdir)/gfortran.map. (BUILT_SOURCES): Add $(version_dep). * Makefile.in: Regenerated. * gfortran.map (GFORTRAN_8): Don't export _gfortran_transfer_complex128, _gfortran_transfer_complex128_write, _gfortran_transfer_real128 and _gfortran_transfer_real128_write if HAVE_GFC_REAL_17 is defined. (GFORTRAN_12): Export those here instead.
generated by cgit v1.1 at 2024-09-28 22:01:39 +0000