aboutsummaryrefslogtreecommitdiff
path: root/libgfortran
AgeCommit message (Collapse)AuthorFilesLines
2022-10-13Daily bump.GCC Administrator1-0/+4
2022-10-12regenerate configure filesMartin Liska1-2/+2
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.
2022-10-12Daily bump.GCC Administrator1-0/+5
2022-10-11Generic configury support for shared libs on VxWorksOlivier Hainque1-0/+43
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.
2022-10-11Daily bump.GCC Administrator1-0/+5
2022-10-10libgfortran: Use `__gthread_t` instead of `pthread_t`LIU Hao1-1/+1
It used to cause errors if a thread model other than `posix` was selected, which looks like a leftover from a79878585a1c5e32bafbc6d1e73f91fd6e4293bf. 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>
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.
generated by cgit v1.1 at 2024-10-21 02:32:58 +0000