[Bug libfortran/94694] New: [libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[Bug libfortran/94694] New: [libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[akrl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

            Bug ID: 94694
           Summary: [libgfortran] libgfortran does not compile on
                    bare-metal aarch64-none-elf (newlib)
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: akrl at gcc dot gnu.org
  Target Milestone: ---

As discussed here 

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

bare-metal (newlib) aarch64-none-elf build is broken possibly by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=faa0817311f43e0d4d223d53c816b0c74ec35c4e

Reporting as new PR so release manager are aware.

====

gcc/libgfortran/intrinsics/trigd.inc: In function 'sind_r16':
gcc/libgfortran/intrinsics/trigd_lib.inc:55:56: error: implicit declaration of
function 'copysignl' [-Werror=implicit-function-declaration]
   55 | #define mpfr_copysign(rop, op1, op2, rnd) rop = SUFFIX(copysign)((op1),
(op2))
      |                                                        ^~~~~~~~

gcc/libgfortran/intrinsics/trigd_lib.inc:57:46: error: implicit declaration of
function 'fabsl' [-Werror=implicit-function-declaration]

gcc/libgfortran/intrinsics/trigd_lib.inc:84:28: error: implicit declaration of
function 'fmal' [-Werror=implicit-function-declaration]
   84 | #define FMA(x,y,z)  SUFFIX(fma)((x), (y), (z))
      |                            ^~~

gcc/libgfortran/intrinsics/trigd_lib.inc:76:45: error: implicit declaration of
function 'cosl' [-Werror=implicit-function-declaration]
   76 | #define mpfr_cos(rop, x, rnd) (rop = SUFFIX(cos)(x))
      |                                             ^~~


gcc/libgfortran/intrinsics/trigd_lib.inc:75:45: error: implicit declaration of
function 'sinl' [-Werror=implicit-function-declaration]
   75 | #define mpfr_sin(rop, x, rnd) (rop = SUFFIX(sin)(x))
      |                                             ^~~


gcc/libgfortran/intrinsics/trigd_lib.inc:77:45: error: implicit declaration of
function 'tanl' [-Werror=implicit-function-declaration]
   77 | #define mpfr_tan(rop, x, rnd) (rop = SUFFIX(tan)(x))
      |                                             ^~~

[Bug libfortran/94694] [libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[akrl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

akrl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.0
     Ever confirmed|0                           |1
           Severity|blocker                     |normal
             Target|                            |aarch64
      Known to fail|                            |10.0
            Summary|[libgfortran] libgfortran   |[10
                   |does not compile on         |Regression][libgfortran]
                   |bare-metal aarch64-none-elf |libgfortran does not
                   |(newlib)                    |compile on bare-metal
                   |                            |aarch64-none-elf (newlib)
   Last reconfirmed|                            |2020-04-21
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |build
                 CC|                            |ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed, I see it too.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note in another bug it was said that libgfortran requires a C99 runtime, when
that's not available you should disable gfortran build.  GCC (or libgfortran)
is in no position to disable parts of its features and AFAICS for QOI issues
the _frontend_ would need to reject programs making use of disabled library
functionality, otherwise programs are going to only fail to link.

IMHO failure at runtime when the disabled functionality is actually invoked
isn't good QOI either.

Re-implementing missing functions in libgfortran isn't trivial either.

Since Fortran isn't release critical the only P1-ish part is that fortran
build is enabled on aarch64-elf and thus we can resolve this by adding
aarch64-elf-*) to

# Disable Fortran for some systems.
case "${target}" in
  mmix-*-*)
    # See <http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00572.html>.
    unsupported_languages="$unsupported_languages fortran"
    ;;
  bpf-*-*)
    unsupported_languages="$unsupported_languages fortran"
    ;;
esac

technically aarch64-elf isn't a primary architecture.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=94586

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
PR94586 for a build fail on hpux which lacks fmaf

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
libgfortran already has a huge collection of fallback functions, in
intrinsics/c99_functions.c
and so IMNSHO we should just handle fma{,f,l} and copysign in there, we already
handle copysignf there.
A fallback for fma can be just x * y + z, I know it isn't perfect, but didn't
glibc have that for more than a decade?
copysign fallback can be __builtin_copysign if configure proves it is not
expanded by the compiler as copysign call, I think we emit it inline on all
sane arches.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #5 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> Note in another bug it was said that libgfortran requires a C99 runtime,
> when that's not available you should disable gfortran build.  GCC (or
> libgfortran)
> is in no position to disable parts of its features and AFAICS for QOI issues
> the _frontend_ would need to reject programs making use of disabled library
> functionality, otherwise programs are going to only fail to link.
> 
> IMHO failure at runtime when the disabled functionality is actually invoked
> isn't good QOI either.
> 
> Re-implementing missing functions in libgfortran isn't trivial either.
> 
> Since Fortran isn't release critical the only P1-ish part is that fortran
> build is enabled on aarch64-elf and thus we can resolve this by adding
> aarch64-elf-*) to
> 
> # Disable Fortran for some systems.
> case "${target}" in
>   mmix-*-*)
>     # See <http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00572.html>.
>     unsupported_languages="$unsupported_languages fortran"
>     ;;
>   bpf-*-*)
>     unsupported_languages="$unsupported_languages fortran"
>     ;;
> esac
> 
> technically aarch64-elf isn't a primary architecture.

Well in that case it should *test* the run time for compatibility.  It
shouldn't assume it's incompatible just because of the target triplet.

aarch64-elf is a secondary platform.  It should still build.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Richard Biener from comment #2)
...
> > Since Fortran isn't release critical the only P1-ish part is that fortran
> > build is enabled on aarch64-elf and thus we can resolve this by adding
> > aarch64-elf-*) to
> > 
> > # Disable Fortran for some systems.
> > case "${target}" in
> >   mmix-*-*)
> >     # See <http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00572.html>.
> >     unsupported_languages="$unsupported_languages fortran"
> >     ;;
> >   bpf-*-*)
> >     unsupported_languages="$unsupported_languages fortran"
> >     ;;
> > esac
> > 
> > technically aarch64-elf isn't a primary architecture.
> 
> Well in that case it should *test* the run time for compatibility.  It
> shouldn't assume it's incompatible just because of the target triplet.
> 
> aarch64-elf is a secondary platform.  It should still build.

Sure, that makes it P1-ish.  But since fortran and thus its runtime
library are not part of the release criteria disabling it [by default]
is a valid fix for that.  Or one could read the criteria that
only --enable-languages=c,c++ is relevant for bootstrap.

Yeah, the criteria as written are probably not the best, but they are
what they are.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I meant something like:
--- libgfortran/configure.ac.jj 2020-01-24 22:34:36.340641225 +0100
+++ libgfortran/configure.ac    2020-04-21 18:03:02.494598615 +0200
@@ -392,6 +392,9 @@ GCC_CHECK_MATH_FUNC([cabsl])
 GCC_CHECK_MATH_FUNC([floorf])
 GCC_CHECK_MATH_FUNC([floor])
 GCC_CHECK_MATH_FUNC([floorl])
+GCC_CHECK_MATH_FUNC([fmaf])
+GCC_CHECK_MATH_FUNC([fma])
+GCC_CHECK_MATH_FUNC([fmal])
 GCC_CHECK_MATH_FUNC([fmodf])
 GCC_CHECK_MATH_FUNC([fmod])
 GCC_CHECK_MATH_FUNC([fmodl])
--- libgfortran/intrinsics/c99_functions.c.jj   2020-01-12 11:54:38.736378361
+0100
+++ libgfortran/intrinsics/c99_functions.c      2020-04-21 18:00:54.368527655
+0200
@@ -229,6 +229,17 @@ ceilf (float x)
 }
 #endif

+#if !defined(HAVE_COPYSIGN) && HAVE_INLINE_BUILTIN_COPYSIGN
+#define HAVE_COPYSIGN 1
+double copysign (double x, double y);
+
+double
+copysign (double x, double y)
+{
+  return __builtin_copysign (x, y);
+}
+#endif
+
 #ifndef HAVE_COPYSIGNF
 #define HAVE_COPYSIGNF 1
 float copysignf (float x, float y);
@@ -2112,3 +2123,36 @@ lgammaf (float x)
   return (float) lgamma ((double) x);
 }
 #endif
+
+#ifndef HAVE_FMA
+#define HAVE_FMA 1
+double fma (double, double, double);
+
+double
+fma (double x, double y, double z)
+{
+  return x * y + z;
+}
+#endif
+
+#ifndef HAVE_FMAF
+#define HAVE_FMAF 1
+float fmaf (float, float, float);
+
+float
+fmaf (float x, float y, float z)
+{
+  return fma (x, y, z);
+}
+#endif
+
+#ifndef HAVE_FMAL
+#define HAVE_FMAL 1
+long double fmaf (long double, long double, long double);
+
+long double
+fmaf (long double x, long double y, long double z)
+{
+  return x * y + z;
+}
+#endif

except that the test in configure for HAVE_INLINE_BUILTIN_COPYSIGN still needs
to be written.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Fritz Reese <foreese at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |foreese at gcc dot gnu.org

--- Comment #8 from Fritz Reese <foreese at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> So, I meant something like:
> --- libgfortran/configure.ac.jj	2020-01-24 22:34:36.340641225 +0100
> +++ libgfortran/configure.ac	2020-04-21 18:03:02.494598615 +0200
> @@ -392,6 +392,9 @@ GCC_CHECK_MATH_FUNC([cabsl])
>  GCC_CHECK_MATH_FUNC([floorf])
>  GCC_CHECK_MATH_FUNC([floor])
>  GCC_CHECK_MATH_FUNC([floorl])
> +GCC_CHECK_MATH_FUNC([fmaf])
> +GCC_CHECK_MATH_FUNC([fma])
> +GCC_CHECK_MATH_FUNC([fmal])
>  GCC_CHECK_MATH_FUNC([fmodf])
>  GCC_CHECK_MATH_FUNC([fmod])
>  GCC_CHECK_MATH_FUNC([fmodl])
[...]
> 
> except that the test in configure for HAVE_INLINE_BUILTIN_COPYSIGN still
> needs to be written.

I like this solution in principle but we would need to add fabsl, fmal, and
copysignl, right? And then we are still left with the question: what do we do
if HAVE_INLINE_BUILTIN_COPYSIGN, HAVE_FMOD, or similar are not satisfied at the
lowest level?

(In reply to Richard Biener from comment #2)
> Note in another bug it was said that libgfortran requires a C99 runtime,
> when that's not available you should disable gfortran build.  GCC (or
> libgfortran)
> is in no position to disable parts of its features and AFAICS for QOI issues
> the _frontend_ would need to reject programs making use of disabled library
> functionality, otherwise programs are going to only fail to link.
> 
> IMHO failure at runtime when the disabled functionality is actually invoked
> isn't good QOI either.
[...]

Yes, I agree. The FE should notify the user for intrinsics which would not be
implemented in the library, if we indeed selectively disable such intrinsics. 

Note that, there is currently precedent for this in the library without
concurrence of the FE: libgfortran/intrinsic/symlnk.c contains the definitions
of the SYMLNK intrinsic (symlnk_iX_sub) guarded by "#ifdef HAVE_SYMLINK". There
is no parallel check in the FE, so I imagine that on a system for which
HAVE_SYMLINK is not defined one would experience a link failure (if there is
any such system on which gfortran can be built).

(In reply to Richard Earnshaw from comment #5)
> (In reply to Richard Biener from comment #2)
> > [...]
> > Since Fortran isn't release critical the only P1-ish part is that fortran
> > build is enabled on aarch64-elf and thus we can resolve this by adding
> > aarch64-elf-*) to
> > [...]
> > technically aarch64-elf isn't a primary architecture.
> 
> Well in that case it should *test* the run time for compatibility.  It
> shouldn't assume it's incompatible just because of the target triplet.
> 
> aarch64-elf is a secondary platform.  It should still build.

I concur. Perhaps a narrower solution is to disable REAL(1[06]) support on the
platform if the *l math functions are not available... Though I prefer Jakub's
solution of providing the missing functions in c99_functions.c so long as the
core functionailty is available on the system.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48326&action=edit
gcc10-pr94694.patch

Completely untested full patch.  Will try to test it on x86_64-linux where it
hopefully shouldn't change anything, but have no (easy) way to test on targets
where it is actually needed.

Re: [Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[Andrea Corallo]

"jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
>
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 48326
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48326&action=edit
> gcc10-pr94694.patch
>
> Completely untested full patch.  Will try to test it on x86_64-linux where it
> hopefully shouldn't change anything, but have no (easy) way to test on targets
> where it is actually needed.

Hi Jakub,

great I'll do some testing too then thanks.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #10 from Andrea Corallo <andrea.corallo at arm dot com> ---
"jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
>
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 48326
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48326&action=edit
> gcc10-pr94694.patch
>
> Completely untested full patch.  Will try to test it on x86_64-linux where it
> hopefully shouldn't change anything, but have no (easy) way to test on targets
> where it is actually needed.

Hi Jakub,

great I'll do some testing too then thanks.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Fritz Reese from comment #8)
> I like this solution in principle but we would need to add fabsl, fmal, and
> copysignl, right? And then we are still left with the question: what do we
> do if HAVE_INLINE_BUILTIN_COPYSIGN, HAVE_FMOD, or similar are not satisfied
> at the lowest level?

I don't know what else is missing, I understood the problem is with copysign,
fma, fmaf and fmal.
copysignl can be handled like copysign just using __builtin_copysignl,
fabs and fabsf can be handled like copysign too, again gcc will usually expand
those inline.
One needs to have very weird floating point format, and such arches will likely
either not support libgfortran, or will have support in libm.  So we can defer
further fallback until somebody reports it doesn't work somewhere.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #12 from Fritz Reese <foreese at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 48326 [details]
> gcc10-pr94694.patch
> 
> Completely untested full patch.  Will try to test it on x86_64-linux where
> it hopefully shouldn't change anything, but have no (easy) way to test on
> targets where it is actually needed.

There is a typo under "#ifndef HAVE_FMAL" (c99_functions.c:2151). fmaf is
re-defined where fmal should be defined.


(In reply to Jakub Jelinek from comment #11)
> (In reply to Fritz Reese from comment #8)
> > I like this solution in principle but we would need to add fabsl, fmal, and
> > copysignl, right? And then we are still left with the question: what do we
> > do if HAVE_INLINE_BUILTIN_COPYSIGN, HAVE_FMOD, or similar are not satisfied
> > at the lowest level?
> 
> I don't know what else is missing, I understood the problem is with
> copysign, fma, fmaf and fmal.
> copysignl can be handled like copysign just using __builtin_copysignl,
> fabs and fabsf can be handled like copysign too, again gcc will usually
> expand those inline.
> One needs to have very weird floating point format, and such arches will
> likely either not support libgfortran, or will have support in libm.  So we
> can defer further fallback until somebody reports it doesn't work somewhere.

According to the OP, none of fabsl, fmal, copysignl, cosl, sinl, tanl are
defined. The patch should be extended to provide all of these, utilizing
__builtin_cosl, __builtin_sinl, etc... What you say is right: if those aren't
available, the intrinsic is FUBAR and should not be available for that kind.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've missed that.  I'm afraid there is no way around missing sinl/cosl/tanl
etc.,
those aren't likely implemented inline by the compiler.  The only exception
would be for targets where long double and double are the same type.
What has libgfortran been doing before?  Seems to me it just wouldn't define
the _gfortran* entrypoint that use them.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> I've missed that.  I'm afraid there is no way around missing sinl/cosl/tanl
> etc.,
> those aren't likely implemented inline by the compiler.  The only exception
> would be for targets where long double and double are the same type.
> What has libgfortran been doing before?  Seems to me it just wouldn't define
> the _gfortran* entrypoint that use them.

But if long double is 64-bit, there is no really a point to use the *l suffixed
functions, is it?

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Thus, I think we can extend the patch I've attached (and fix the two fmaf to
fmal spots), plus do the HAVE_INLINE_BUILTIN_* in configure.ac either through a
config/math.m4 macro, or through a loop over the functions that can have such
treatment with a likely inlined implementation.

But still, the trig*.inc needs to check HAVE_* macros of everything that it
uses and just don't provide the definitions if it can't be implemented.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 21 Apr 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
> 
> --- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Thus, I think we can extend the patch I've attached (and fix the two fmaf to
> fmal spots), plus do the HAVE_INLINE_BUILTIN_* in configure.ac either through a
> config/math.m4 macro, or through a loop over the functions that can have such
> treatment with a likely inlined implementation.
> 
> But still, the trig*.inc needs to check HAVE_* macros of everything that it
> uses and just don't provide the definitions if it can't be implemented.

Maybe they can be implemented like

long double _gfortran_xyz (long double x)
{
  __sorry_fortran_intrinsic_xyz_is_not_available_because_cosl_is_not ();
}

instead of simply not providing them.  Coordination between the FE
and (the various multilibs of) libgfortran and emitting diagnostics
from the FE would of course be even better.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #16)
> Maybe they can be implemented like
> 
> long double _gfortran_xyz (long double x)
> {
>   __sorry_fortran_intrinsic_xyz_is_not_available_because_cosl_is_not ();
> }
> 
> instead of simply not providing them.  Coordination between the FE
> and (the various multilibs of) libgfortran and emitting diagnostics
> from the FE would of course be even better.

libgfortran has runtime_error or internal_error and other functions that can
deliver messages to the user, sure.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #18 from Fritz Reese <foreese at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > I've missed that.  I'm afraid there is no way around missing sinl/cosl/tanl
> > etc.,
> > those aren't likely implemented inline by the compiler.  The only exception
> > would be for targets where long double and double are the same type.
> > What has libgfortran been doing before?  Seems to me it just wouldn't define
> > the _gfortran* entrypoint that use them.
> 
> But if long double is 64-bit, there is no really a point to use the *l
> suffixed functions, is it?

If long double is 64-bit, then neither REAL(10) nor REAL(16) will be available,
since the kinds are set by precision / 8. Then HAVE_GFC_REAL_16 and
HAVE_GFC_REAL_10 are not defined, in which case the *l suffixed version is not
built. The problem comes when REAL(10) or REAL(16) are supported by the system,
but the system's libm does not declare or define the math builtins for that
precision.

(In reply to Jakub Jelinek from comment #15)
> Thus, I think we can extend the patch I've attached (and fix the two fmaf to
> fmal spots), plus do the HAVE_INLINE_BUILTIN_* in configure.ac either
> through a config/math.m4 macro, or through a loop over the functions that
> can have such treatment with a likely inlined implementation.
> 

According to comments in pr94586, it seems that on HPUX __builtin_cosl is
available but a proper "cosl" is not. I'm not sure how this happens but it
suggests to me that a similar pattern might work for the trig functions, at
least sometimes.

(In reply to Jakub Jelinek from comment #17)
> (In reply to rguenther@suse.de from comment #16)
> > Maybe they can be implemented like
> > 
> > long double _gfortran_xyz (long double x)
> > {
> >   __sorry_fortran_intrinsic_xyz_is_not_available_because_cosl_is_not ();
> > }
> > 
> > instead of simply not providing them.  Coordination between the FE
> > and (the various multilibs of) libgfortran and emitting diagnostics
> > from the FE would of course be even better.
> 
> libgfortran has runtime_error or internal_error and other functions that can
> deliver messages to the user, sure.

Yes, I think we should use this approach at least. It is not immediately clear
to me how to properly check this in the FE. I think checking HAVE_* at compiler
compile time in the FE is wrong. I don't know what/how the FE can inquire about
the library at compile (run) time.

> But still, the trig*.inc needs to check HAVE_* macros of everything that it
> uses and just don't provide the definitions if it can't be implemented.

I will provide a patch which handles the checks in trigd*.inc. I have no
experience writing m4/autoconf so I would appreciate help streamlining that
side. The best I could do quickly is to simply extend your patch with copy |
paste | sed and touching up c99_functions.c. I expect there is probably some
better way to reduce duplication, thus opportunities for typos.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Working on it now.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48326|0                           |1
        is obsolete|                            |

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48329&action=edit
gcc10-pr94694.patch

Updated patch for the easy fallbacks, untested (will test on x86_64-linux, but
that won't tell much, because all the functions should be provided there by
libm).

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #21 from Fritz Reese <foreese at gcc dot gnu.org> ---
Created attachment 48332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48332&action=edit
Patch to protect trigd functions based on system availability

Patch for trigd include pieces to check for HAVE_XXX[*]. If a required piece is
not defined, the function is replaced with simply a runtime_error().

@akrl and @ktkachov, please combine this with Jakub's patch and see how the
build goes. Like Jakub I am also on x86_64-linux and it is difficult to
exercise all the conditions.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I have now bootstrapped/regtested #c20 + #c21 on x86_64-linux and i686-linux
but I see
+FAIL: gfortran.dg/dec_math.f90   -O0  execution test
+FAIL: gfortran.dg/dec_math.f90   -O1  execution test
+FAIL: gfortran.dg/dec_math.f90   -O2  execution test
+FAIL: gfortran.dg/dec_math.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gfortran.dg/dec_math.f90   -O3 -g  execution test
+FAIL: gfortran.dg/dec_math.f90   -Os  execution test
on both (no other FAILs and the abilists on libgfortran.so.? are the same on
both).

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #23 from Andrea Corallo <andrea.corallo at arm dot com> ---
"foreese at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
>
> --- Comment #21 from Fritz Reese <foreese at gcc dot gnu.org> ---
> Created attachment 48332
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48332&action=edit
> Patch to protect trigd functions based on system availability
>
> Patch for trigd include pieces to check for HAVE_XXX[*]. If a required piece is
> not defined, the function is replaced with simply a runtime_error().
>
> @akrl and @ktkachov, please combine this with Jakub's patch and see how the
> build goes. Like Jakub I am also on x86_64-linux and it is difficult to
> exercise all the conditions.

Hi,

I confirm that combining the two patches works for me for building
aarch64-none-elf now.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The dec_math.f90 FAILs are at all opt levels:
( ) qsind( 60.000000000000000000000000000000)  0.866025403784438646763723170753
 0.866025403784438596588302061718
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG
STOP 1

If I preprocess trigd.c before/after the #c21 patch, the difference (appart
from lines/whitespace) are:
-   (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f)));
+   (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06));

-       (x = 8.66025388e-01f);
+       (x = 8.66025388e-01);

-   (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f)));
+   (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06));

-       (x = 8.66025388e-01f);
+       (x = 8.66025388e-01);

...
-  static const volatile GFC_REAL_10 tiny = 0x1.p-16400L;
+  static const volatile GFC_REAL_10 tiny = 0x1.p-16400l;
...
-       (x = 8.66025403784438646787e-01L);
+       (x = 8.66025403784438646787e-01);
...
-   (x = fmal(((x)), (1.74532925229868851602e-02L), ((x) *
-3.04358939097084072823e-12L)));
+   (x = fmal((x), 1.74532925229868851602e-02, (x) *
-3.04358939097084072823e-12));
...
-       (x = 8.66025403784438646763723170752936183e-01q);
+       (x = 8.66025403784438646763723170752936183e-01);

etc., so all that matters is that some float suffixes (f, , L, q) are gone from
the constants (and the L -> l change on tiny and a few others), which of course
matters a lot.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #25 from Fritz Reese <foreese at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #24)
> The dec_math.f90 FAILs are at all opt levels:
> ( ) qsind( 60.000000000000000000000000000000) 
> 0.866025403784438646763723170753  0.866025403784438596588302061718
> Note: The following floating-point exceptions are signalling:
> IEEE_INVALID_FLAG
> STOP 1
> 
> If I preprocess trigd.c before/after the #c21 patch, the difference (appart
> from lines/whitespace) are:
> -   (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f)));
> +   (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06));
> 
> -       (x = 8.66025388e-01f);
> +       (x = 8.66025388e-01);
> 
> -   (x = fmaf(((x)), (1.74560547e-02f), ((x) * -2.76216747e-06f)));
> +   (x = fmaf((x), 1.74560547e-02, (x) * -2.76216747e-06));
> 
> -       (x = 8.66025388e-01f);
> +       (x = 8.66025388e-01);
> 
> ...
> -  static const volatile GFC_REAL_10 tiny = 0x1.p-16400L;
> +  static const volatile GFC_REAL_10 tiny = 0x1.p-16400l;
> ...
> -       (x = 8.66025403784438646787e-01L);
> +       (x = 8.66025403784438646787e-01);
> ...
> -   (x = fmal(((x)), (1.74532925229868851602e-02L), ((x) *
> -3.04358939097084072823e-12L)));
> +   (x = fmal((x), 1.74532925229868851602e-02, (x) *
> -3.04358939097084072823e-12));
> ...
> -       (x = 8.66025403784438646763723170752936183e-01q);
> +       (x = 8.66025403784438646763723170752936183e-01);
> 
> etc., so all that matters is that some float suffixes (f, , L, q) are gone
> from the constants (and the L -> l change on tiny and a few others), which
> of course matters a lot.

Ah, yes, I missed some LITERAL(x) wrappings. Will fix and post an updated patch
shortly.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[foreese at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Fritz Reese <foreese at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #48332|0                           |1
        is obsolete|                            |
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |foreese at gcc dot gnu.org

--- Comment #26 from Fritz Reese <foreese at gcc dot gnu.org> ---
Created attachment 48351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48351&action=edit
Patch to protect trigd functions based on system availability (v2)

I've attached a new patch for trigd. Below is the delta on top of the old
patch. I'm building and testing now. Jakub, if you concur, I will commit these
patches and close the PR after successful testing.

diff --git a/libgfortran/intrinsics/trigd_lib.inc
b/libgfortran/intrinsics/trigd_lib.inc
index 66e22c3845e..e90f9deaa5a 100644
--- a/libgfortran/intrinsics/trigd_lib.inc
+++ b/libgfortran/intrinsics/trigd_lib.inc
@@ -128,9 +128,9 @@ PIO180L               -- lower bits of pi/180 for FMA
 #define mpz_cmp_ui(x, y) ((x) - (y))
 #define mpz_divisible_ui_p(n, d) ((n) % (d) == 0)

-#define D2R(x) (x = FMA((x), PIO180H, (x) * PIO180L))
+#define D2R(x) (x = FMA((x), PIO180H_LITERAL, (x) * PIO180L_LITERAL))

-#define SET_COSD30(x) (x = COSD30)
+#define SET_COSD30(x) (x = COSD30_LITERAL)

 #ifdef SIND
 extern FTYPE SIND (FTYPE);

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Fritz Reese from comment #26)
> Created attachment 48351 [details]
> Patch to protect trigd functions based on system availability (v2)
> 
> I've attached a new patch for trigd. Below is the delta on top of the old
> patch. 

With that incremental change, trigd.i differences look good to me during brief
skimming.

> I'm building and testing now. Jakub, if you concur, I will commit
> these patches and close the PR after successful testing.

I've already posted my patch to the mailing list, if somebody approves it,
I'll check it in.
I think we don't urgently need another round of aarch64-none-elf testing with
the incremental patch, because for a target that doesn't have those cosl etc.
functions in newlib ENABLE_SIND etc. will not be defined and so the incremental
patch shouldn't change anything.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #28 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1868599f8daf7798018ce8a8f314015f5a2ac520

commit r10-7893-g1868599f8daf7798018ce8a8f314015f5a2ac520
Author: Jakub Jelinek <jakub@redhat.com>
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  <jakub@redhat.com>

            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/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #29 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Fritz Reese <foreese@gcc.gnu.org>:

https://gcc.gnu.org/g:e8eecc2a919033ad4224756a8759d8e94c0e4bc2

commit r10-7913-ge8eecc2a919033ad4224756a8759d8e94c0e4bc2
Author: Fritz Reese <foreese@gcc.gnu.org>
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  <foreese@gcc.gnu.org>

            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  <foreese@gcc.gnu.org>

            * trigd_fe.inc: Use mpfr to compute cosd(30) rather than a host-
            precision floating point literal based on an invalid macro.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Hopefully fixed.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #31 from Andrea Corallo <andrea.corallo at arm dot com> ---
I confirm master now builds for me aarch64-none-elf.