This Fortran code: > program p > use, intrinsic :: ieee_arithmetic, only: IEEE_IS_NAN > write(*,*) ieee_is_nan(5.0) > end fails on these architectures: > Fatal Error: Cannot find an intrinsic module named 'ieee_arithmetic' Testcases: science/siesta, science/dftbplus
On architectures in question the file finclude/ieee_arithmetic.mod isn't installed.
As it turned out GCC doesn't yet support IEEE754 on aarch64 and powerpc. On aarch64 the fpu-aarch64.h file is missing in their tree. Same problem with powerpc. Please feel free to close this bug or to keep it open, because the problem is still present. Certain ports need to be left with limited architectures.
(In reply to Yuri Victorovich from comment #2) > > As it turned out GCC doesn't yet support IEEE754 on aarch64 and powerpc. > This is incorrect FUD. gfortran supports IEEE modules on these architectures on any system using glibc. > On aarch64 the fpu-aarch64.h file is missing in their tree. > Same problem with powerpc. This is a woeful interpretation of what was written in the GCC bug report. If fenv.h is supported by FreeBSD on these architectures, then someone with access to aarch64-*-freebsd (and powerpc) needs to adjust the file libgforan/configure.host to look for fenv capabilities. > Please feel free to close this bug or to keep it open, because the problem > is still present. Certain ports need to be left with limited architectures. Note, the Fortran standard does not require a conforming Fortran processor to provide the IEEE modules. Until someone from FreeBSD land looks into providing the support gfortran of aarch64 and powerpc is fully standard conforming. BTW, a trivially stupid patch to test is diff --git a/libgfortran/configure.host b/libgfortran/configure.host index e9d92c9d34d..0fece4b98b6 100644 --- a/libgfortran/configure.host +++ b/libgfortran/configure.host @@ -75,3 +75,7 @@ case "${target}" in esac +# kludge to test if aarch64-*-freebsd works +fpu_host='fpu-glibc' +ieee_support='yes' +
(In reply to Yuri Victorovich from comment #2) > Please feel free to close this bug or to keep it open, because the problem > is still present. Certain ports need to be left with limited architectures. Given there is an upstream bug for this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 and there's some thoughts what it requires to address this (which GCC nicely does on Linux/glibc platforms) let's close this one.
(In reply to Gerald Pfeifer from comment #4) @Gerald As the maintainer of the port this report is for, it would be great if you could keep yourself assigned and close it in the manner you deem most appropriate, otherwise bugs just languish with no clear way forward. If you're not sure of a path forward, you can close an issue with an appropriate resolution, and ask future interested folks to re-open it later with additional information of a concrete proposal/patch
Yes, that's what I actually meant to do. For lack of a "RESOLVED UPSTREAM" setting in our Bugzilla, using "RESOLVED Overcome By Events".
(In reply to Gerald Pfeifer from comment #6) Thanks!