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.
