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.