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
