[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 John David Anglin changed: What|Removed |Added Attachment #48357|0 |1 is obsolete|| --- Comment #45 from John David Anglin --- Created attachment 48901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48901&action=edit Patch to use libquadmath with gfortran on hpux This patch enables the use of libquadmath with gfortran on hpux. There is no system support for long double (or __flat128) math, so it would be nice if we could use the libquadmath support for __float128. The attached patch works with both 32 and 64-bit hpux targets. There are a couple of testsuite fails that I haven't had time to investigate yet. But mostly it works.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-07-20 Priority|P3 |P4 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #44 from Dominique d'Humieres --- Target issue?
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #43 from John David Anglin --- The fix for PR 94694 fixed the build on hppa2.0w-hp-hpux11.11. We are left with the following new fails in dec_math.f90: FAIL: gfortran.dg/dec_math.f90 -O0 (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O0 execution test FAIL: gfortran.dg/dec_math.f90 -O1 (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O1 execution test FAIL: gfortran.dg/dec_math.f90 -O2 (test for excess errors) 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 (test for excess errors) 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 (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O3 -g execution test FAIL: gfortran.dg/dec_math.f90 -Os (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -Os execution test This is caused by the missing 'l' suffix routines: spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/dec_math.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O0 -cpp -std=gnu -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libatomic/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o ./dec_math.exe /usr/ccs/bin/ld: Unsatisfied symbols: tanl (first referenced in /var/tmp//ccQhSJVu.o) (code) asinl (first referenced in /var/tmp//ccQhSJVu.o) (code) sinl (first referenced in /var/tmp//ccQhSJVu.o) (code) acosl (first referenced in /var/tmp//ccQhSJVu.o) (code) atanl (first referenced in /var/tmp//ccQhSJVu.o) (code) atan2l (first referenced in /var/tmp//ccQhSJVu.o) (code) cosl (first referenced in /var/tmp//ccQhSJVu.o) (code) collect2: error: ld returned 1 exit status compiler exited with status 1 While I will continue to work on a change to use the 'q' routines from libquadmath on hppa-hpux, this is of lower priority.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #42 from Jakub Jelinek --- I think this one is not fixed yet, there is some pa hpux specific patch. See e.g. #c39.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #41 from Richard Biener --- If this is now fixed can you close the bug as such please, John?
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 Bug 94586 depends on bug 94694, which changed state. Bug 94694 Summary: [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #40 from CVS Commits --- The master branch has been updated by Fritz Reese : https://gcc.gnu.org/g:e8eecc2a919033ad4224756a8759d8e94c0e4bc2 commit r10-7913-ge8eecc2a919033ad4224756a8759d8e94c0e4bc2 Author: Fritz Reese Date: Wed Apr 22 11:45:22 2020 -0400 Protect the trigd functions in libgfortran from unavailable math functions. libgfortran/ChangeLog: 2020-04-22 Fritz Reese PR libfortran/94694 PR libfortran/94586 * intrinsics/trigd.c, intrinsics/trigd_lib.inc, intrinsics/trigd.inc: Guard against unavailable math functions. Use suffixes from kinds.h based on the REAL kind. gcc/fortran/ChangeLog: 2020-04-22 Fritz Reese * trigd_fe.inc: Use mpfr to compute cosd(30) rather than a host- precision floating point literal based on an invalid macro.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 John David Anglin changed: What|Removed |Added Attachment #48356|0 |1 is obsolete|| --- Comment #39 from John David Anglin --- Created attachment 48357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48357&action=edit Patch to fix float128 node selection on hpux Modify mk-kinds-h.sh to auto detect whether to use long double or __float128 for REAL(16).
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #38 from John David Anglin --- Because mk-kinds-h.sh has not been modifies, we still get long double in kinds.h with gcc-10: typedef long double GFC_REAL_16; typedef complex long double GFC_COMPLEX_16; However with my patch, this does not seem to matter. The following program function foo(x) real(16) foo, x foo = cos(x) end function foo generates a call to cosq.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 John David Anglin changed: What|Removed |Added Attachment #48352|0 |1 is obsolete|| --- Comment #37 from John David Anglin --- Created attachment 48356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48356&action=edit Patch to fix float128 node selection on hpux Fix build (missing target.h include). I'm going to remove libgfortran changes and retest.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #36 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1868599f8daf7798018ce8a8f314015f5a2ac520 commit r10-7893-g1868599f8daf7798018ce8a8f314015f5a2ac520 Author: Jakub Jelinek Date: Wed Apr 22 19:17:15 2020 +0200 libgfortran: Provide some further math library fallbacks [PR94694] The following patch provides some further math library fallbacks. fmaf can be implemented using fma if available, fma and fmal can use x * y + z as fallback, it is not perfect, but e.g. glibc on various arches has been using that as fallback for many years, and copysign/copysignl/fabs/fabsl can be implemented using corresponding __builtin_* if we make sure that gcc expands it inline instead of using a library call (these days it is expanded inline on most targets). 2020-04-22 Jakub Jelinek PR libfortran/94694 PR libfortran/94586 * configure.ac: Add math func checks for fmaf, fma and fmal. Add HAVE_INLINE_BUILTIN_COPYSIGN check. * c99_protos.h (copysign, fmaf, fma, fmal): Provide fallback prototypes. (HAVE_COPYSIGN, HAVE_FMAF, HAVE_FMA, HAVE_FMAL): Define if not defined and fallback version is provided. * intrinsics/c99_functions.c (copysign, fmaf, fma, fmal): Provide fallback implementations if possible * configure: Regenerated. * config.h.in: Regenerated. * math.m4 (GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK1, GCC_CHECK_MATH_INLINE_BUILTIN_FALLBACK2): New.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #35 from dave.anglin at bell dot net --- On 2020-04-22 12:27 p.m., sgk at troutmask dot apl.washington.edu wrote: > I suspect that having HPUX map > > REAL(4) <--> float ! f suffix > REAL(8) <--> double ! no suffix > REAL(16) <--> __float128 ! q suffix > > may cause issues with either ISO C binding or IEEE 754 module > or both. Why? It's what HP did? On ia64, libm contains a full quad implementation with q suffix. Both l and w sufixes are used with 80-bit floating types (long double and double extended). Many targets have double and long double both mapped to the same 64-bit floating type. So, I don't see why long double and __float128 can't be mapped to the same 128-bit floating type. It's been that way for years.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #34 from Steve Kargl --- On Wed, Apr 22, 2020 at 04:02:01PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #33 from dave.anglin at bell dot net --- > On 2020-04-22 10:54 a.m., foreese at gcc dot gnu.org wrote: > > If you have a functional gfortran you can also generate it with > > "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to > > expose the core type which gfortran uses for REAL(16) according to the > > target. > Looking at script, I see it has same logic to disambiguate long double and > float128: > 16) if [ $long_double_kind -eq 10 ]; then > ctype="__float128" > cplxtype="_Complex float __attribute__((mode(TC)))" > suffix="q" > else > ctype="long double" > cplxtype="complex long double" > suffix="l" > fi ;; > > It always selects long double when both are REAL(16). > Which is the correct assumption that I already explained. Both the ISO C binding module and the IEEE 754 modules assume a C99 type mapping. There are only 2 cases: REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(10) <--> long double ! l suffix REAL(16) <--> __float128 ! q suffix or REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(16) <--> long double ! l suffix (if long double exists) I suspect that having HPUX map REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(16) <--> __float128 ! q suffix may cause issues with either ISO C binding or IEEE 754 module or both.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #33 from dave.anglin at bell dot net --- On 2020-04-22 10:54 a.m., foreese at gcc dot gnu.org wrote: > If you have a functional gfortran you can also generate it with > "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to > expose the core type which gfortran uses for REAL(16) according to the target. Looking at script, I see it has same logic to disambiguate long double and float128: 16) if [ $long_double_kind -eq 10 ]; then ctype="__float128" cplxtype="_Complex float __attribute__((mode(TC)))" suffix="q" else ctype="long double" cplxtype="complex long double" suffix="l" fi ;; It always selects long double when both are REAL(16).
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #32 from John David Anglin --- Created attachment 48354 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48354&action=edit Header file This is kinds.h generated with gcc-8. Note we have "typedef long double GFC_REAL_16;". I'm attempting to change this to float128 so that we use libquadmath instead of the non existent support for long double.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #31 from dave.anglin at bell dot net --- Fritz, I have a build going with the patch which I just attached. I realized last night that the change I made to address the problem with iroundq was wrong. I should be able to answer your questions shortly. I haven't looked at the patches in pr94694 but I believe that configure should be able to detect the core type used for REAL(16) from gfortran. kinds-override.h seems like a hack to me.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 John David Anglin changed: What|Removed |Added Attachment #48331|0 |1 is obsolete|| --- Comment #30 from John David Anglin --- Created attachment 48352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48352&action=edit Patch to fix float128 node selection on hpux Restore change to fix float128 builtins. Handle iround specially.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 Fritz Reese changed: What|Removed |Added CC||foreese at gcc dot gnu.org --- Comment #29 from Fritz Reese --- John, I wonder could you output your generated kinds.h? It will be in $GCCBUILD/stageN-/libgfortran/kinds.h if your build has made it far enough. If you have a functional gfortran you can also generate it with "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to expose the core type which gfortran uses for REAL(16) according to the target. I'd also like to know the results of building with the two patches in pr94694. I think you should keep the target-specific portions of your patch, including mods to gcc/fortran/trans-types.c, but I think you should then be able to drop the changes to libgfortran/intrinsics/trigd.c and libgfortran/kinds-override.h.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 John David Anglin changed: What|Removed |Added Attachment #48327|0 |1 is obsolete|| --- Comment #28 from John David Anglin --- Created attachment 48331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48331&action=edit Patch to fix float128 node selection on hpux Fix tm.texi.in.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #27 from John David Anglin --- This build on hppa2.0w-hp-hpux11.11 had a previous version of my float128 patch: https://gcc.gnu.org/pipermail/gcc-testresults/2020-April/559390.html
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 John David Anglin changed: What|Removed |Added Attachment #48295|0 |1 is obsolete|| --- Comment #26 from John David Anglin --- Created attachment 48327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48327&action=edit Patch to fix float128 node selection on hpux This is my latest patch to fix the float128. In this iteration, I have attempted to create a target hook to allow REAL16 to be float128 instead of long double. Previous version had a problem with iroundq. Need to use long double builtins. This version is untested. With previous version, there was one new test fail (probably it didn't run before) and one XPASS. So, using libquadmath is working out quite well. Have no objection to having configure checks for fmaf and fma. That's better than my POSIX check. Sorry, this is going slowly but testing takes awhile.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #25 from Jakub Jelinek --- Perhaps the PR94694 patch could help (or further extended version thereof).
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #24 from Steve Kargl --- On Thu, Apr 16, 2020 at 09:32:46PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #23 from dave.anglin at bell dot net --- > On 2020-04-16 5:07 p.m., sgk at troutmask dot apl.washington.edu wrote: > > It is unclear to me if the patch will meet everyone's > > expectation. In particular, there are currently no > > target-specific macros used in the Fortran frontend. > > Using 'defined(__hpux__)' may make some unhappy as > > it now complicates maintenance and adding new Fortran > > features. > Can I include "../../libgfortran/libgfortran.h" in these frontend routines? > This would pull in > the defines for GFC_REAL_16_IS_FLOAT128 and GFC_REAL_16_IS_LONG_DOUBLE. > That might be worse, but you're in territory that I've not tread. I suggest you send an email to both fortran@ and gcc@ asking for input from more experienced contributors. Don't hold your breath too long on fortran@ replies. Several of us have stop contributing because of the git transition.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #23 from dave.anglin at bell dot net --- On 2020-04-16 5:07 p.m., sgk at troutmask dot apl.washington.edu wrote: > It is unclear to me if the patch will meet everyone's > expectation. In particular, there are currently no > target-specific macros used in the Fortran frontend. > Using 'defined(__hpux__)' may make some unhappy as > it now complicates maintenance and adding new Fortran > features. Can I include "../../libgfortran/libgfortran.h" in these frontend routines? This would pull in the defines for GFC_REAL_16_IS_FLOAT128 and GFC_REAL_16_IS_LONG_DOUBLE.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #22 from Steve Kargl --- On Thu, Apr 16, 2020 at 08:06:00PM +, danglin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #21 from John David Anglin --- > Created attachment 48295 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48295&action=edit > Patch to fix float128 node selection on hpux > > With this change, the libquadmath routines are now selected on hpux. > > Testing. > It is unclear to me if the patch will meet everyone's expectation. In particular, there are currently no target-specific macros used in the Fortran frontend. Using 'defined(__hpux__)' may make some unhappy as it now complicates maintenance and adding new Fortran features.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #21 from John David Anglin --- Created attachment 48295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48295&action=edit Patch to fix float128 node selection on hpux With this change, the libquadmath routines are now selected on hpux. Testing.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #20 from Steve Kargl ---
On Thu, Apr 16, 2020 at 01:10:21AM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #18 from dave.anglin at bell dot net ---
> On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> > What does -fdump-tree-original show for
> >
> > function foo(x)
> >real(16) foo, x
> >foo = cos(x)
> > end function foo
> foo (real(kind=16) & restrict x)
> {
> real(kind=16) __result_foo;
>
> __result_foo = __builtin_cosl (*x);
> return __result_foo;
> }
This is what I anticipated after I sent the email.
With -fno-builtin, you'll get cosl, which you don't
have. So, you'll need to figure out how to force
gfortran to use 'q' suffixes instead of 'l'. I don't
know how the frontend will handle this. Using weak
references as you suggested in your other reply might
be the easily (if it worked).
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #19 from dave.anglin at bell dot net ---
On 2020-04-15 2:32 p.m., sgk at troutmask dot apl.washington.edu wrote:
> On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote:
>> /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from
> This should be in libquadmath.
>
> % nm /usr/home/kargl/work/lib/libquadmath.a | grep strtoflt
> strtoflt128.o:
> 0880 T strtoflt128
>
This fixes the link issues but we are still left with cosl instead of cosq.
HP-UX doesn't support weak
very well.
diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
index 81699069545..ba92fbd0cb1 100644
--- a/libgfortran/intrinsics/trigd.c
+++ b/libgfortran/intrinsics/trigd.c
@@ -27,6 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include
+#if (_POSIX_VERSION < 200112L)
+#define fmaf(a,b,c) ((a)*(b)+(c))
+#define fma(a,b,c) ((a)*(b)+(c))
+#endif
/*
For real x, let {x}_P or x_P be the closest representible number in the
diff --git a/libgfortran/kinds-override.h b/libgfortran/kinds-override.h
index baa0f7e1cb5..38e70be542a 100644
--- a/libgfortran/kinds-override.h
+++ b/libgfortran/kinds-override.h
@@ -34,7 +34,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran. */
#if defined(HAVE_GFC_REAL_16)
-# if defined(HAVE_GFC_REAL_10)
+# if defined(HAVE_GFC_REAL_10) || defined(__hpux__)
# define GFC_REAL_16_IS_FLOAT128
# if !defined(HAVE_FLOAT128)
# error "Where has __float128 gone?"
diff --git a/libquadmath/quadmath_weak.h b/libquadmath/quadmath_weak.h
index a97c813a013..2bbd2a11233 100644
--- a/libquadmath/quadmath_weak.h
+++ b/libquadmath/quadmath_weak.h
@@ -23,7 +23,7 @@ Boston, MA 02110-1301, USA. */
#include "quadmath.h"
-#if SUPPORTS_WEAK
+#if SUPPORTS_WEAK && !defined(__hpux__)
# define __qmath2(name,name2,type) \
static __typeof(type) name __attribute__ ((__weakref__(#name2))) \
__quadmath_throw;
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #18 from dave.anglin at bell dot net ---
On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> What does -fdump-tree-original show for
>
> function foo(x)
>real(16) foo, x
>foo = cos(x)
> end function foo
foo (real(kind=16) & restrict x)
{
real(kind=16) __result_foo;
__result_foo = __builtin_cosl (*x);
return __result_foo;
}
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #17 from dave.anglin at bell dot net --- On 2020-04-15 2:32 p.m., sgk at troutmask dot apl.washington.edu wrote: > On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote: >> /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from > This should be in libquadmath. > > % nm /usr/home/kargl/work/lib/libquadmath.a | grep strtoflt > strtoflt128.o: > 0880 T strtoflt128 > It is. The problem is read.o is looking for a data symbol. Need to look at libgfortran(read.o): /usr/ccs/bin/ld: Unsatisfied symbols: strtoflt128 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.a(read.o)) (data) There's a missing declaration for strtoflt128.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #16 from dave.anglin at bell dot net --- On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote: > It likely is the start of an approach, but it seems hpux is conflating > long double and __float128, where it flips between an 'l' and 'q' suffix. > gfortran simply assumes a correspondence with C types and C99 naming > conventions (e.g., sinf, sin, and sinl). If a target has REAL(4), REAL(8), > REAL(10), and REAL(16) the correspondence is float, double, long double, > and __float128, respectively. If a target has REAL(4), REAL(8), and REAL(16), > then the correspondence is float, double, and long double. There is no > __float128, and by extension, no functions with a 'q' suffix. The long > double math function will end in 'l'. It's not hpux conflating long double and __float128. On hppa, there's a IEEE 128-bit float type defined in the architecture and a limited set of arithmetic routines available to manipulate this type. There's no C99 support until HP-UX 11i version 2. Even then, no long double routines were implemented for PA-RISC. IA64 has REAL(10). There's routine for both double extended (w) and long double (l). Initially, the REAL(10) type was __float80. REAL(16) on IA64 is quad (q). __float128 is not used by HP-UX. There's no REAL(10) or REAL(16) on hppa. Treating REAL(16) as __float128 was my choice some years ago. It seemed compatible with gcc's __float128 on IA64 and I wanted to take advantage of libquadmath if possible.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #15 from Steve Kargl --- On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote: > > /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from This should be in libquadmath. % nm /usr/home/kargl/work/lib/libquadmath.a | grep strtoflt strtoflt128.o: 0880 T strtoflt128 > /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 > /usr/lib/dld.sl: Unresolved module for symbol: _gfortrani_si_max (code) from This should be in libgfortran and comes from libgfortran/io/read.c. It is unclear why it would be missing. Given that confusion that hpux seems to be causing for libgfortran, it seems the --disable-libquadmath is your best option.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #14 from Steve Kargl ---
On Wed, Apr 15, 2020 at 03:28:29PM +, dave.anglin at bell dot net wrote:
>
> On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> >
> > #if defined(HAVE_GFC_REAL_16)
> > # if defined(HAVE_GFC_REAL_10)
> > # define GFC_REAL_16_IS_FLOAT128
> > # if !defined(HAVE_FLOAT128)
> > # error "Where has __float128 gone?"
> > # endif
> > # else
> > # define GFC_REAL_16_IS_LONG_DOUBLE
> > # endif
> > #endif
> >
> > So, hpux does not have REAL(10) and has REAL(16). This is doing
> > what it is designed to do based on the assumption that a target
> > like hpux with REAL(16) will define the long double functions
> > with the 'l' suffix. It seems the the fix for hpux is to change
> > the test to something like
> >
> > # if defined(HAVE_GFC_REAL_10) || defined(__HPUX__)
> >
> > using, of course, whatever the relevant macro. This will then
> > select the 'q' suffix.
>
> I tried the above approach yesterday but it led to a couple of undefined
> symbols in libgfortran that
> caused a new test fail. Possibly, the above might be a better overall
> approach
It likely is the start of an approach, but it seems hpux is conflating
long double and __float128, where it flips between an 'l' and 'q' suffix.
gfortran simply assumes a correspondence with C types and C99 naming
conventions (e.g., sinf, sin, and sinl). If a target has REAL(4), REAL(8),
REAL(10), and REAL(16) the correspondence is float, double, long double,
and __float128, respectively. If a target has REAL(4), REAL(8), and REAL(16),
then the correspondence is float, double, and long double. There is no
__float128, and by extension, no functions with a 'q' suffix. The long
double math function will end in 'l'.
> but this is what I ended
> up doing last night:
>
> diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
> index 81699069545..970c60952ee 100644
> --- a/libgfortran/intrinsics/trigd.c
> +++ b/libgfortran/intrinsics/trigd.c
> @@ -27,6 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If
> not, see
>
> #include
>
> +#if (_POSIX_VERSION < 200112L)
> +#define fmaf(a,b,c) ((a)*(b)+(c))
> +#define fma(a,b,c) ((a)*(b)+(c))
> +#endif
>
> /*
> For real x, let {x}_P or x_P be the closest representible number in the
> @@ -169,7 +173,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If not, see
> #define COSDcosd_r16
> #define TANDtand_r16
>
> -#ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath. */
> +#if defined(GFC_REAL_16_IS_FLOAT128) || !defined(HAVE_COSL) /* libquadmath.
> */
> #define SUFFIX(x) x ## q
> #else
> #define SUFFIX(x) x ## l
>
> This fixed build of trigd.c. I think I need to do something similar to fix
> dec_math.f90:
>
> FAIL: gfortran.dg/dec_math.f90 -O0 (test for excess errors)
> Excess errors:
> /usr/ccs/bin/ld: Unsatisfied symbols:
>tanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>asinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>sinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>acosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>atanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>atan2l (first referenced in /var/tmp//ccLGIJFM.o) (code)
>cosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>
> It's the only new fail.
What does -fdump-tree-original show for
function foo(x)
real(16) foo, x
foo = cos(x)
end function foo
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #13 from dave.anglin at bell dot net --- On 2020-04-15 11:28 a.m., John David Anglin wrote: > I tried the above approach yesterday but it led to a couple of undefined > symbols in libgfortran that > caused a new test fail. The following symbols are missing: /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 /usr/lib/dld.sl: Unresolved module for symbol: _gfortrani_si_max (code) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 This causes abort in PR19872.exe and other tests: 13 read(1,*)i (gdb) warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ec0 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ed8 warning: Unable to find symbol for 0x2ef0 warning: Unable to find symbol for 0x2ef0 warning: Unable to find symbol for 0x2ef0 warning: Unable to find symbol for 0x2ef0 /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 /usr/lib/dld.sl: Unresolved module for symbol: _gfortrani_si_max (code) from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 Program received signal SIGABRT, Aborted. 0xc00423b0 in kill () from /usr/lib/dld.sl
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #12 from dave.anglin at bell dot net ---
On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #11 from Steve Kargl ---
> On Tue, Apr 14, 2020 at 11:46:36PM +, dave.anglin at bell dot net wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>>
>> --- Comment #10 from dave.anglin at bell dot net ---
>> On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote:
>>> So, hppa64 has REAL(16), but it does not use __float128 or
>>> GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead
>>> of the above kludge you can do something like
>> It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate.
>> There's a similar problem with the test dec_math.f90 which has started to
>> fail
>>
>> We have when the hpux long double library is available:
>>
>> /* Under HPUX, the __float128 type is a synonym for "long double". */
>> (*lang_hooks.types.register_builtin_type) (long_double_type_node,
>> "__float128");
>>
>> We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and
>> __builtin_huge_valq.
>> I suppose I could add "l" versions.
>>
>
> This seems to be confusing the simply assumptions in
> libgfortran/kinds-override.h, which states
>
> /* What are the C types corresponding to the real(kind=10) and
>real(kind=16) types? We currently rely on the following assumptions:
> -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined,
> then it is necessarily the "long double" type
> -- if real(kind=16) exists, then:
> * if HAVE_GFC_REAL_10, real(kind=16) is "__float128"
> * otherwise, real(kind=16) is "long double"
>To allow to change this in the future, we create the
>GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran. */
>
> #if defined(HAVE_GFC_REAL_16)
> # if defined(HAVE_GFC_REAL_10)
> # define GFC_REAL_16_IS_FLOAT128
> # if !defined(HAVE_FLOAT128)
> # error "Where has __float128 gone?"
> # endif
> # else
> # define GFC_REAL_16_IS_LONG_DOUBLE
> # endif
> #endif
>
> So, hpux does not have REAL(10) and has REAL(16). This is doing
> what it is designed to do based on the assumption that a target
> like hpux with REAL(16) will define the long double functions
> with the 'l' suffix. It seems the the fix for hpux is to change
> the test to something like
>
> # if defined(HAVE_GFC_REAL_10) || defined(__HPUX__)
>
> using, of course, whatever the relevant macro. This will then
> select the 'q' suffix.
I tried the above approach yesterday but it led to a couple of undefined
symbols in libgfortran that
caused a new test fail. Possibly, the above might be a better overall approach
but this is what I ended
up doing last night:
diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
index 81699069545..970c60952ee 100644
--- a/libgfortran/intrinsics/trigd.c
+++ b/libgfortran/intrinsics/trigd.c
@@ -27,6 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include
+#if (_POSIX_VERSION < 200112L)
+#define fmaf(a,b,c) ((a)*(b)+(c))
+#define fma(a,b,c) ((a)*(b)+(c))
+#endif
/*
For real x, let {x}_P or x_P be the closest representible number in the
@@ -169,7 +173,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
#define COSDcosd_r16
#define TANDtand_r16
-#ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath. */
+#if defined(GFC_REAL_16_IS_FLOAT128) || !defined(HAVE_COSL) /* libquadmath.
*/
#define SUFFIX(x) x ## q
#else
#define SUFFIX(x) x ## l
This fixed build of trigd.c. I think I need to do something similar to fix
dec_math.f90:
FAIL: gfortran.dg/dec_math.f90 -O0 (test for excess errors)
Excess errors:
/usr/ccs/bin/ld: Unsatisfied symbols:
tanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
asinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
sinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
acosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
atanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
atan2l (first referenced in /var/tmp//ccLGIJFM.o) (code)
cosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
It's the only new fail.
It might be better to add configure checks for fmaf and fma.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #11 from Steve Kargl --- On Tue, Apr 14, 2020 at 11:46:36PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #10 from dave.anglin at bell dot net --- > On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote: > > So, hppa64 has REAL(16), but it does not use __float128 or > > GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead > > of the above kludge you can do something like > It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate. > There's a similar problem with the test dec_math.f90 which has started to fail > > We have when the hpux long double library is available: > > /* Under HPUX, the __float128 type is a synonym for "long double". */ > (*lang_hooks.types.register_builtin_type) (long_double_type_node, > "__float128"); > > We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and > __builtin_huge_valq. > I suppose I could add "l" versions. > This seems to be confusing the simply assumptions in libgfortran/kinds-override.h, which states /* What are the C types corresponding to the real(kind=10) and real(kind=16) types? We currently rely on the following assumptions: -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined, then it is necessarily the "long double" type -- if real(kind=16) exists, then: * if HAVE_GFC_REAL_10, real(kind=16) is "__float128" * otherwise, real(kind=16) is "long double" To allow to change this in the future, we create the GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran. */ #if defined(HAVE_GFC_REAL_16) # if defined(HAVE_GFC_REAL_10) # define GFC_REAL_16_IS_FLOAT128 # if !defined(HAVE_FLOAT128) # error "Where has __float128 gone?" # endif # else # define GFC_REAL_16_IS_LONG_DOUBLE # endif #endif So, hpux does not have REAL(10) and has REAL(16). This is doing what it is designed to do based on the assumption that a target like hpux with REAL(16) will define the long double functions with the 'l' suffix. It seems the the fix for hpux is to change the test to something like # if defined(HAVE_GFC_REAL_10) || defined(__HPUX__) using, of course, whatever the relevant macro. This will then select the 'q' suffix.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #10 from dave.anglin at bell dot net --- On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote: > So, hppa64 has REAL(16), but it does not use __float128 or > GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead > of the above kludge you can do something like It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate. There's a similar problem with the test dec_math.f90 which has started to fail We have when the hpux long double library is available: /* Under HPUX, the __float128 type is a synonym for "long double". */ (*lang_hooks.types.register_builtin_type) (long_double_type_node, "__float128"); We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and __builtin_huge_valq. I suppose I could add "l" versions. #ifndef HAVE_COSL #define cosl cosq /* Use libquadmath for hppa64. */ #endif Yes, that seems an option.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #9 from Steve Kargl --- On Tue, Apr 14, 2020 at 08:48:47PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #8 from dave.anglin at bell dot net --- > On 2020-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote: > > #ifdef HAVE_GFC_REAL_16 > > #endif > This one. > > > > Is hppa64 claiming support for a REAL type that it actually > > doesn't support? > Support is a fuzzy word. There's enough support to build libquadmath. So, you have REAL(4), REAL(8), and REAL(16). Is REAL(16) a software implementaton of IEEE 128-bit floating point, which uses libquadmath? If yes, then this suggests the logic to select the suffix 'q' or 'l' needs tweaking as you should be getting, e.g., cosq() from libquadmath instead of cosl(). > > In any event, you can extend the kludge > > > > #if (__STDC_VERSION__ < 199901L) > > #define fmaf(a,b,c) ((a)*(b)+(c)) > > #define fma(a,b,c) ((a)*(b)+(c)) > > #define fmal(a,b,c) ((a)*(b)+(c)) > > #define cosl(a) cos((double)(a)) > > #define sinl(a) sin((double)(a)) > > #define tanl(a) tan((double)(a)) > > #define fabsl(a) ((a) < 0 ? -(a) : (a)) > > #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) > > #endif > I have something that builds now. Need to test. > > I think we need to use _POSIX_VERSION as __STDC_VERSION__ is set by cpp. Looking at trigd.c, one finds #ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath. */ #define SUFFIX(x) x ## q #else #define SUFFIX(x) x ## l #endif /* GFC_REAL_16_IS_FLOAT128 */ So, hppa64 has REAL(16), but it does not use __float128 or GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead of the above kludge you can do something like #ifndef HAVE_COSL #define cosl cosq /* Use libquadmath for hppa64. */ #endif HAVE_COSL, HAVE_SINL, HAVE_TANL are definitely available. I don't recall if fabsl and copysignl have similar macros.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #8 from dave.anglin at bell dot net --- On 2020-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote: > #ifdef HAVE_GFC_REAL_16 > #endif This one. > > Is hppa64 claiming support for a REAL type that it actually > doesn't support? Support is a fuzzy word. There's enough support to build libquadmath. > > In any event, you can extend the kludge > > #if (__STDC_VERSION__ < 199901L) > #define fmaf(a,b,c) ((a)*(b)+(c)) > #define fma(a,b,c) ((a)*(b)+(c)) > #define fmal(a,b,c) ((a)*(b)+(c)) > #define cosl(a) cos((double)(a)) > #define sinl(a) sin((double)(a)) > #define tanl(a) tan((double)(a)) > #define fabsl(a) ((a) < 0 ? -(a) : (a)) > #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) > #endif I have something that builds now. Need to test. I think we need to use _POSIX_VERSION as __STDC_VERSION__ is set by cpp. Dave
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #7 from Steve Kargl --- On Tue, Apr 14, 2020 at 05:24:51PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #6 from dave.anglin at bell dot net --- > On 2020-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote: > > After '#include ' in trigd.c, add > > > > #if (__STDC_VERSION__ < 199901L) > > #define fmaf(a,b,c) ((a)*(b)+(c)) > > #define fma(a,b,c) ((a)*(b)+(c)) > > #define fmal(a,b,c) ((a)*(b)+(c)) > > #endif > > > Unfortunately, we also need copysignl, fabsl, cosl, sinl and tanl. > How are you getting to these? These are protected by #ifdef HAVE_GFC_REAL_10 #endif or #ifdef HAVE_GFC_REAL_16 #endif Is hppa64 claiming support for a REAL type that it actually doesn't support? In any event, you can extend the kludge #if (__STDC_VERSION__ < 199901L) #define fmaf(a,b,c) ((a)*(b)+(c)) #define fma(a,b,c) ((a)*(b)+(c)) #define fmal(a,b,c) ((a)*(b)+(c)) #define cosl(a) cos((double)(a)) #define sinl(a) sin((double)(a)) #define tanl(a) tan((double)(a)) #define fabsl(a) ((a) < 0 ? -(a) : (a)) #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) #endif
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #6 from dave.anglin at bell dot net --- On 2020-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote: > After '#include ' in trigd.c, add > > #if (__STDC_VERSION__ < 199901L) > #define fmaf(a,b,c) ((a)*(b)+(c)) > #define fma(a,b,c) ((a)*(b)+(c)) > #define fmal(a,b,c) ((a)*(b)+(c)) > #endif > Unfortunately, we also need copysignl, fabsl, cosl, sinl and tanl.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #5 from Steve Kargl --- On Tue, Apr 14, 2020 at 12:55:45PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #4 from dave.anglin at bell dot net --- > On 2020-04-13 11:02 p.m., kargl at gcc dot gnu.org wrote: > > Does math.h define fmaf? If yes, this this is bogus bug report. > > If no, please disable building gfortran on hppa64. > No, math.h does not define fmaf. > After '#include ' in trigd.c, add #if (__STDC_VERSION__ < 199901L) #define fmaf(a,b,c) ((a)*(b)+(c)) #define fma(a,b,c) ((a)*(b)+(c)) #define fmal(a,b,c) ((a)*(b)+(c)) #endif
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #4 from dave.anglin at bell dot net --- On 2020-04-13 11:02 p.m., kargl at gcc dot gnu.org wrote: > Does math.h define fmaf? If yes, this this is bogus bug report. > If no, please disable building gfortran on hppa64. No, math.h does not define fmaf. Build was okay as of 20200403: https://gcc.gnu.org/pipermail/gcc-testresults/2020-April/558420.html === gfortran tests === Running target unix FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O0 execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O1 execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O2 execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -O3 -g execution test FAIL: gfortran.dg/unlimited_polymorphic_30.f03 -Os execution test === gfortran Summary === # of expected passes51686 # of unexpected failures6 # of expected failures 201 # of unsupported tests 428 /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran version 10.0.1 20200403 (experimental) (GCC) I presume this was introduced by the following commit: commit 57391ddaf39f7cb85825c32e83feb1435889da51 Author: Fritz Reese Date: Tue Apr 7 11:59:36 2020 -0400 Fix PR fortran/93871 and re-implement degree-valued trigonometric intrinsics. 2020-04-01 Fritz Reese Steven G. Kargl gcc/fortran/ChangeLog PR fortran/93871
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #3 from Steve Kargl --- On Tue, Apr 14, 2020 at 07:23:32AM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #2 from Richard Biener --- > Not all targets have a C99 math runtime. libgfortran configury tests for a > load > of C99 functions: > > # Check for C99 (and other IEEE) math functions > GCC_CHECK_MATH_FUNC([acosf]) > GCC_CHECK_MATH_FUNC([acos]) > GCC_CHECK_MATH_FUNC([acosl]) > GCC_CHECK_MATH_FUNC([acoshf]) > ... > > but fails to check for fma[lf ] (I also don't see any uses of the HAVE_* > macros defined but that's another issue. > It is 2020. If a target doesn't support C99, then building gfortran should be prohibited. The file libgfortran/intrinsics/c99_functions.c is nothing but a kludge, and I wrote a part of that file! I also note that FreeBSD does not have a complete C99 and building libstdc++ is broken because of this. Yet, I can't get a trivially stupid patch applied. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #2 from Richard Biener --- Not all targets have a C99 math runtime. libgfortran configury tests for a load of C99 functions: # Check for C99 (and other IEEE) math functions GCC_CHECK_MATH_FUNC([acosf]) GCC_CHECK_MATH_FUNC([acos]) GCC_CHECK_MATH_FUNC([acosl]) GCC_CHECK_MATH_FUNC([acoshf]) ... but fails to check for fma[lf ] (I also don't see any uses of the HAVE_* macros defined but that's another issue.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- This appears to be a bogus report. (In reply to John David Anglin from comment #0) > libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc > -B/test/gnu/gcc/objdir/./gcc/ > -B/opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/bin/ > -B/opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/lib/ -isystem > /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/include -isystem > /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/sys-include -fchecking=1 > -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran > -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc > -I../../../gcc/libgfortran/../gcc/config > -I../../../gcc/libgfortran/../libquadmath -I../.././gcc > -I../../../gcc/libgfortran/../libgcc -I../libgcc > -I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace > -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -Wextra -Wwrite-strings > -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules > -ffunction-sections -fdata-sections -g -O2 -MT trigd.lo -MD -MP -MF > .deps/trigd.Tpo -c ../../../gcc/libgfortran/intrinsics/trigd.c -DPIC -o > .libs/trigd.o > ../../../gcc/libgfortran/intrinsics/trigd.inc: In function 'sind_r4': > ../../../gcc/libgfortran/intrinsics/trigd_lib.inc:84:28: error: implicit > declaration of function 'fmaf' [-Werror=implicit-function-declaration] >84 | #define FMA(x,y,z) SUFFIX(fma)((x), (y), (z)) > |^~~ > Does math.h define fmaf? If yes, this this is bogus bug report. If no, please disable building gfortran on hppa64.
