[fortran, patch] IEEE intrinsic modules (ping)

[FX]

Hi Steve,

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.

> 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? 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])])

checking only if libc or libm contain any call to a feenableexcept() function. Is it a macro on FreeBSD?


3. Does the attached updated patch (libgfortran only, without regenerated files) fix the problem?

FX




-------------- next part --------------
A non-text attachment was scrubbed...
Name: x
Type: application/octet-stream
Size: 86108 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20140624/3910573c/attachment.obj>