As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many
times in the back case if nothing is found.
For !back, the loops are for (i = 1; i <= extent; i++) so i is in the
body [1, extent] if nothing is found, but for back it is
for (i = extent; i >= 0; i--) so i is in the body [0, extent] and compares
one element before the start of the array.
Note, findloc1_s{1,4} uses
for (n = len; n > 0; n--, src -= delta * len_array)
for the back loop and
for (n = 1; n <= len; n++, src += delta * len_array)
for !back. This patch fixes that.
The testcase fails under valgrind without the libgfortran changes and
succeeds with those.
2025-05-13 Jakub Jelinek <jakub@redhat.com>
PR libfortran/120196
* m4/ifindloc2.m4 (header1, header2): For back use i > 0 rather than
i >= 0 as for condition.
* generated/findloc2_s1.c: Regenerate.
* generated/findloc2_s4.c: Regenerate.
* gfortran.dg/pr120196.f90: New test.
(cherry picked from commit 748a7bc462)
There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the
following testcase shows.
The functions return but then crash in the caller.
Seems that is because buffer overflows, I believe those functions for
if (mask == NULL || *mask) condition being false are supposed to fill in
the result array with all zeros (or allocate it and fill it with zeros).
My understanding is the result array in that case is integer(kind={4,8,16})
and should have the extents the character input array has.
The problem is that it uses * string_len in the extent multiplication:
extent[n] = GFC_DESCRIPTOR_EXTENT(array,n) * string_len;
and
extent[n] =
GFC_DESCRIPTOR_EXTENT(array,n + 1) * string_len;
which is I guess fine and desirable for the extents of the character array,
but not for the extents of the destination array. Yet the code uses
that extent array for that purpose (and no other purposes).
Here it uses it to set the dimensions for the case where it needs to
allocate (as well as size):
for (n = 0; n < rank; n++)
{
if (n == 0)
str = 1;
else
str = GFC_DESCRIPTOR_STRIDE(retarray,n-1) * extent[n-1];
GFC_DIMENSION_SET(retarray->dim[n], 0, extent[n] - 1, str);
}
Here it uses it for bounds checking of the destination:
if (unlikely (compile_options.bounds_check))
{
for (n=0; n < rank; n++)
{
index_type ret_extent;
ret_extent = GFC_DESCRIPTOR_EXTENT(retarray,n);
if (extent[n] != ret_extent)
runtime_error ("Incorrect extent in return value of"
" MAXLOC intrinsic in dimension %ld:"
" is %ld, should be %ld", (long int) n + 1,
(long int) ret_extent, (long int) extent[n]);
}
}
and here to find out how many retarray elements to actually fill in each
dimension:
while(1)
{
*dest = 0;
count[0]++;
dest += dstride[0];
n = 0;
while (count[n] == extent[n])
{
/* When we get to the end of a dimension, reset it and increment
the next dimension. */
count[n] = 0;
/* We could precalculate these products, but this is a less
frequently used path so probably not worth it. */
dest -= dstride[n] * extent[n];
Seems maxloc1s.m4 and minloc1s.m4 are the only users of ifunction-s.m4,
so we can change SCALAR_ARRAY_FUNCTION in there without breaking anything
else.
2025-05-13 Jakub Jelinek <jakub@redhat.com>
PR fortran/120191
* m4/ifunction-s.m4 (SCALAR_ARRAY_FUNCTION): Don't multiply
GFC_DESCRIPTOR_EXTENT(array,) by string_len.
* generated/maxloc1_4_s1.c: Regenerate.
* generated/maxloc1_4_s4.c: Regenerate.
* generated/maxloc1_8_s1.c: Regenerate.
* generated/maxloc1_8_s4.c: Regenerate.
* generated/maxloc1_16_s1.c: Regenerate.
* generated/maxloc1_16_s4.c: Regenerate.
* generated/minloc1_4_s1.c: Regenerate.
* generated/minloc1_4_s4.c: Regenerate.
* generated/minloc1_8_s1.c: Regenerate.
* generated/minloc1_8_s4.c: Regenerate.
* generated/minloc1_16_s1.c: Regenerate.
* generated/minloc1_16_s4.c: Regenerate.
* gfortran.dg/pr120191_3.f90: New test.
(cherry picked from commit 781cfc454b)
I've tried to write a testcase for the BT_CHARACTER maxloc/minloc with named
or unnamed arguments and indeed the just posted patch fixed the arguments
in there in multiple cases to match what the library expects.
But the testcase still fails, due to library problems.
One dealt with in this patch are _gfortran_s{max,min}loc2_{4,8,16}_s{1,4}
functions. Those are trivial wrappers around
_gfortrani_{max,min}loc2_{4,8,16}_s{1,4} which should call those functions
if the scalar mask is true and just return 0 otherwise.
The two bugs I see there is that the back, len arguments are swapped,
which means that it always acts as back=.true. and for len will use
character length of 1 or 0 instead of the desired one.
The _gfortrani_{max,min}loc2_{4,8,16}_s{1,4} functions have prototypes like
GFC_INTEGER_4
maxloc2_4_s1 (gfc_array_s1 * const restrict array, GFC_LOGICAL_4 back, gfc_charlen_type len)
so back comes before len, ditto for the
GFC_INTEGER_4
smaxloc2_4_s1 (gfc_array_s1 * const restrict array,
GFC_LOGICAL_4 *mask, GFC_LOGICAL_4 back, gfc_charlen_type len)
The other problem is that it was just testing if (mask). In my limited
Fortran understanding that means that the optional argument mask was
supplied but nothing about its actual value. Other scalar mask generated
routines use if (mask == NULL || *mask) as the condition when to call the
non-masked function, i.e. when mask is not supplied (then it should act like
.true. mask) or when it is supplied and evaluates to .true.).
2025-05-13 Jakub Jelinek <jakub@redhat.com>
PR fortran/120191
* m4/maxloc2s.m4: For smaxloc2 call maxloc2 if mask is NULL or *mask.
Swap back and len arguments.
* m4/minloc2s.m4: Likewise.
* generated/maxloc2_4_s1.c: Regenerate.
* generated/maxloc2_4_s4.c: Regenerate.
* generated/maxloc2_8_s1.c: Regenerate.
* generated/maxloc2_8_s4.c: Regenerate.
* generated/maxloc2_16_s1.c: Regenerate.
* generated/maxloc2_16_s4.c: Regenerate.
* generated/minloc2_4_s1.c: Regenerate.
* generated/minloc2_4_s4.c: Regenerate.
* generated/minloc2_8_s1.c: Regenerate.
* generated/minloc2_8_s4.c: Regenerate.
* generated/minloc2_16_s1.c: Regenerate.
* generated/minloc2_16_s4.c: Regenerate.
* gfortran.dg/pr120191_2.f90: New test.
(cherry picked from commit 482f2192d4)
The linking of libgcc is already present in %(liborig), so the current
situation duplicates libraries. This was not an issue until macOS's new
linker started giving warnings for such cases.
libgfortran/ChangeLog:
PR libfortran/110651
* libgfortran.spec.in: Remove duplicate libraries.
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.
(cherry picked from commit e205ec03f0)
(This cherry pick excludes an accidentally committed file, which was
removed in follow-up commit 18af26fc375398f0a7cd7bae5aabebd447f8c899.)
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.
The following patch expands IEEE_CLASS inline in the FE but only for the
powerpc64le-linux IEEE quad real(kind=16), using the __builtin_fpclassify
builtin and explicit check of the MSB mantissa bit in place of missing
__builtin_signbit builtin.
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.
(cherry picked from commit db630423a9)
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}.
(cherry picked from commit 82ac4cd213)
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.
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.
These two files were introduced by mistake in
86e3b476d5
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/signaling_3.f90: Remove file.
libgfortran/ChangeLog:
* ieee/issignaling_fallback.h: Remove file.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This brings the library to compile with all specific functions.
It also corrects the patsubst patterns so the right files
get the flags.
It was necessary to manually add -D__powerpc64__ because apparently
this is not set for Fortran.
libgfortran/ChangeLog:
* Makefile.am: Correct files for compilation flags. Add
-D__powerpc64__ for Fortran sources. Get kinds.inc from
grep of kinds.h and kinds-override.h.
* Makefile.in: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add -mno-gnu-attribute to compile flags.
* generated/_abs_c17.F90: Regenerate.
* generated/_abs_r17.F90: Regenerate.
* generated/_acos_r17.F90: Regenerate.
* generated/_acosh_r17.F90: Regenerate.
* generated/_aimag_c17.F90: Regenerate.
* generated/_aint_r17.F90: Regenerate.
* generated/_anint_r17.F90: Regenerate.
* generated/_asin_r17.F90: Regenerate.
* generated/_asinh_r17.F90: Regenerate.
* generated/_atan2_r17.F90: Regenerate.
* generated/_atan_r17.F90: Regenerate.
* generated/_atanh_r17.F90: Regenerate.
* generated/_conjg_c17.F90: Regenerate.
* generated/_cos_c17.F90: Regenerate.
* generated/_cos_r17.F90: Regenerate.
* generated/_cosh_r17.F90: Regenerate.
* generated/_dim_r17.F90: Regenerate.
* generated/_exp_c17.F90: Regenerate.
* generated/_exp_r17.F90: Regenerate.
* generated/_log10_r17.F90: Regenerate.
* generated/_log_c17.F90: Regenerate.
* generated/_log_r17.F90: Regenerate.
* generated/_mod_r17.F90: Regenerate.
* generated/_sign_r17.F90: Regenerate.
* generated/_sin_c17.F90: Regenerate.
* generated/_sin_r17.F90: Regenerate.
* generated/_sinh_r17.F90: Regenerate.
* generated/_sqrt_c17.F90: Regenerate.
* generated/_sqrt_r17.F90: Regenerate.
* generated/_tan_r17.F90: Regenerate.
* generated/_tanh_r17.F90: Regenerate.
* kinds-override.h: Adjust to trunk.
Change condition to single line so it can be grepped.
* m4/specific.m4: Make sure that real=kind16 is used
for _r17.F90 and _c17.F90 files.
* m4/specific2.m4: Likewise.
The following patch quiets
../../../libgfortran/generated/in_pack_r17.c:35:1: warning: no previous prototype for ‘internal_pack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_pack_c17.c:35:1: warning: no previous prototype for ‘internal_pack_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_unpack_r17.c:33:1: warning: no previous prototype for ‘internal_unpack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/in_unpack_c17.c:33:1: warning: no previous prototype for ‘internal_unpack_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/pack_r17.c:73:1: warning: no previous prototype for ‘pack_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/pack_c17.c:73:1: warning: no previous prototype for ‘pack_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_r17.c:34:1: warning: no previous prototype for ‘unpack0_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_r17.c:178:1: warning: no previous prototype for ‘unpack1_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_c17.c:34:1: warning: no previous prototype for ‘unpack0_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/unpack_c17.c:178:1: warning: no previous prototype for ‘unpack1_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_r17.c:34:1: warning: no previous prototype for ‘spread_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_r17.c:230:1: warning: no previous prototype for ‘spread_scalar_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_c17.c:34:1: warning: no previous prototype for ‘spread_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/spread_c17.c:230:1: warning: no previous prototype for ‘spread_scalar_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift0_r17.c:33:1: warning: no previous prototype for ‘cshift0_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift0_c17.c:33:1: warning: no previous prototype for ‘cshift0_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_4_r17.c:32:1: warning: no previous prototype for ‘cshift1_4_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_4_c17.c:32:1: warning: no previous prototype for ‘cshift1_4_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_8_r17.c:32:1: warning: no previous prototype for ‘cshift1_8_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_8_c17.c:32:1: warning: no previous prototype for ‘cshift1_8_c17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_16_r17.c:32:1: warning: no previous prototype for ‘cshift1_16_r17’ [-Wmissing-prototypes]
../../../libgfortran/generated/cshift1_16_c17.c:32:1: warning: no previous prototype for ‘cshift1_16_c17’ [-Wmissing-prototypes]
warnings during libgfortran build and exports the new entrypoints.
Note, not all of them, clearly e.g. there are fewer *_r17* entrypoints than
*_r16* entrypoints, so more work is needed.
2021-12-31 Jakub Jelinek <jakub@redhat.com>
* libgfortran.h (internal_pack_r17, internal_pack_c17,
internal_unpack_r17, internal_unpack_c17, pack_r17, pack_c17,
unpack0_r17, unpack0_c17, unpack1_r17, unpack1_c17, spread_r17,
spread_c17, spread_scalar_r17, spread_scalar_c17, cshift0_r17,
cshift0_c17, cshift1_4_r17, cshift1_8_r17, cshift1_16_r17,
cshift1_4_c17, cshift1_8_c17, cshift1_16_c17): Declare.
* gfortran.map (GFORTRAN_12): Export *_r17 and *_c17.
Richard Biener