[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.