bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture

[Mark H Weaver]

Vasiliy <address@hidden> writes:

> It's just to highlight I've got that error of:
> fail: scm_from_double (1) == +nan.0
> FAIL: test-conversion.exe
>
> while compiling with:
> CFLAGS="-mtune=native -march=native -Ofast -fomit-frame-pointer"

I now see the problem.  -Ofast implies -ffast-math, which implies
-funsafe-math-optimizations, -ffinite-math-only, etc.  Specifically,
this enabled the compiler to optimize (guile_Inf / guile_Inf) to 1.0,
which foiled Guile's attempt to create a NaN object.

>From the GCC manual (Optimize Options):

`-Ofast'
     Disregard strict standards compliance.  `-Ofast' enables all `-O3'
     optimizations.  It also enables optimizations that are not valid
     for all standard compliant programs.  It turns on `-ffast-math'
     and the Fortran-specific `-fno-protect-parens' and
     `-fstack-arrays'.

My recommendation would be to avoid -Ofast, not just in Guile but in
general.  It is likely to create subtle problems in a lot of software.

Things like language interpreters in particular tend to push the
boundaries of standards compliance, and are likely to be broken in
subtle ways by -Ofast.

It's reasonable and sometimes useful to use -Ofast in isolated modules
containing hot code, but only in modules whose -Ofast safety has been
investigated by someone who understands the associated compiler
optimizations, and is familiar with the kinds of breakage that can
occur.

> There's, however, still an error with 'test-ffi', and there's no
> automatic invocation of 'numbers.test'.

Strange.  Did you run "make check" in the top-level build directory?

If that doesn't work, maybe try: "./check-guile numbers.test"

> Would be there any support for -Ofast in future?

I doubt that we would officially support it.  It's possible that the
bugs introduced by -Ofast will not affect you, I don't know.  At the
very least, you are likely to get incorrect answers from the numerics
library in some cases.  There might be more serious problems as well.
Some of these problems might be discovered by our test suite, which you
don't seem to be running most of.  Others might remain undetected.

> Just one point more here: the latest autogen when compiled
> --with-guile=2.2 refers to 'scm_subr_table' not present in mainstream
> Guile.

This indicates that you compiled against Guile 1.8's headers.  You'll
need to arrange to have Guile 2.2's headers come first in the search
path.  I guess the --with-libguile option to autogen's configure is what
you need.

     Regards,
       Mark