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.
