On Tue, Jun 24, 2014 at 09:43:06PM +0200, FX wrote: > > Thanks for testing on a platform I don?t have access to! I try to > answer to the three main points below: > > > I suppose I don't understand the logic in libgfortran/configure.host. > > It is picking the wrong config/fpu*.h file. > > 1. This is a preexisting bug, then. Currently, we have 4 versions > of the FPU-specific code: > > ? fpu-glibc.h works on any platform that has C99 fenv.h + > feenableexcept(), fedisableexcept() & fegetexcept() extensions > ? fpu-387.h aims at x86/x86_64 systems, and should have priority > over fpu-glibc.h (because it allows for control of denormals, > which the above does not have) > ? fpu-aix.h requires C99 fenv.h + many AIX extensions (fp_trap(), > fp_enable(), fp_disable(), fp_is_enabled(), fp_invalid_op()) > ? fpu-sysv.h requires many SysV function calls: fpgetmask(), > fpgetround(), fpgetsticky(), etc. > > The logic in configure.host clearly does not accomodate targets who > have two styles of calls. I think it should be moved around so that > the order of priority is aix < sysv < glibc < 387.
This would work on FreeBSD and probably the other *BSD systems. > > FreeBSD (and the other *BSD) have both feenbleexcept() and > > fpsetmask(), but neither check is correct. It seems the check > > for feenableexcept assumes glibc and fpsetmask assumes SysV > > system. > > 2. How does the check fail? To get past the build failure, I changed configure.host to use have_fp_except instead of have_fpsetmask. With FreeBSD the defined type is fp_except_t instead of the SysV fp_except. if test "x${have_fp_except}" = "xyes"; then fpu_host='fpu-sysv' ieee_support='yes' fi I haven't checked to see if haev_dp_except is actually set/unset by configure. With this change I pick up fpu-i387.h and the build completes as expected. I'm now in the regression testing stage. > What does the config.log say? It > looks like a pretty generic check in configure.ac: > > AC_CHECK_LIB([m],[feenableexcept],[have_feenableexcept=yes > AC_DEFINE([HAVE_FEENABLEEXCEPT],[1],[libm includes feenableexcept])]) config.h eventually ends up with /* libm includes feenableexcept */ #define HAVE_FEENABLEEXCEPT 1 /* Define to 1 if you have the <fenv.h> header file. */ #define HAVE_FENV_H 1 /* Define if you have fpsetmask. */ #define HAVE_FPSETMASK 1 /* Define to 1 if the system has the type `fp_except'. */ /* #undef HAVE_FP_EXCEPT */ /* Define to 1 if the system has the type `fp_except_t'. */ #define HAVE_FP_EXCEPT_T 1 /* Define to 1 if the system has the type `fp_rnd'. */ /* #undef HAVE_FP_RND */ /* Define to 1 if the system has the type `fp_rnd_t'. */ #define HAVE_FP_RND_T 1 > checking only if libc or libm contain any call to a feenableexcept() > function. Is it a macro on FreeBSD? It is function. The problem seems to be that fpu-sysv.h assumes the types fp_except and fp_rnd whereas FreeBSD has fp_except_t and fp_rnd_t. > 3. Does the attached updated patch (libgfortran only, without > regenerated files) fix the problem? I'll test it when my regtesting is completed. But, a scan of the configure.host re-arrangement suggests that it should work. -- Steve