From: Vasiliy <testtest_2005@ukr.net>
To: Mark H Weaver <mhw@netris.org>
Cc: 14789@debbugs.gnu.org
Subject: bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture
Date: Sat, 6 Jul 2013 22:11:42 +0200 [thread overview]
Message-ID: <CAHYyVz446iiJuu=WnF-Lf2TE2LzO7x85uUPu8SKt3=OLx1iQKg@mail.gmail.com> (raw)
In-Reply-To: <877gh3a4ji.fsf@tines.lan>
Hi, Mark,
Sorry for my previous double-posting to the guile-devel maillist; just
at that time I didn't have a reply from guile-bugs'.
I've run ./check-guile numbers.test, yes, it hasn't been invoked my
"make check" from the top-level build directory. For the latest Guile
compiled with CFLAGS="-mtune=native -march=native -O2" I've got the
following:
$ ./check-guile numbers.test
Testing /usr/src/64bit/release/guile/guile-2.1.0-57/build/meta/guile
... numbers.test
with GUILE_LOAD_PATH=/usr/src/64bit/release/guile/guile-2.1.0-57/src/guile-2.1.0/test-suite
Running numbers.test
FAIL: numbers.test: inexact->exact: smallest inexact: pos - arguments:
(expected-value
1/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact: neg - arguments:
(expected-value
-1/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 2: pos -
arguments: (expected-value
1/101201126653655309176247673359458653524778324882071059178450679013715169783997673445980191850718562247593538932158405955694904368692896738433506699970369254960758712138283180682233453871046608170619883839236372534281003741712346349309051677824579778170405028256179384776166707307615251266093163754323003131653853870546747392
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 2: neg -
arguments: (expected-value
-1/101201126653655309176247673359458653524778324882071059178450679013715169783997673445980191850718562247593538932158405955694904368692896738433506699970369254960758712138283180682233453871046608170619883839236372534281003741712346349309051677824579778170405028256179384776166707307615251266093163754323003131653853870546747392
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 3: pos -
arguments: (expected-value
3/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)
FAIL: numbers.test: inexact->exact: smallest inexact * 3: neg -
arguments: (expected-value
-3/202402253307310618352495346718917307049556649764142118356901358027430339567995346891960383701437124495187077864316811911389808737385793476867013399940738509921517424276566361364466907742093216341239767678472745068562007483424692698618103355649159556340810056512358769552333414615230502532186327508646006263307707741093494784
actual-value 0)
Totals for this test run:
passes: 28367
failures: 6
unexpected passes: 0
expected failures: 0
unresolved test cases: 0
untested test cases: 0
unsupported test cases: 0
errors: 0
Regards,
Vasiliy
On Sat, Jul 6, 2013 at 9:09 PM, Mark H Weaver <mhw@netris.org> wrote:
> Vasiliy <testtest_2005@ukr.net> 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
next prev parent reply other threads:[~2013-07-06 20:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 13:56 bug#14789: BUG: Modules compile as ELF's on PE/PE+ architecture Vasiliy
2013-07-05 16:23 ` Mark H Weaver
2013-07-06 9:01 ` Vasiliy
2013-07-06 19:09 ` Mark H Weaver
2013-07-06 20:11 ` Vasiliy [this message]
2013-07-07 9:46 ` Vasiliy
2013-07-11 15:33 ` bug#14789: Fwd: " Vasiliy
2013-07-12 10:14 ` Vasiliy
2013-07-12 15:42 ` Vasiliy
2016-06-21 6:53 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHYyVz446iiJuu=WnF-Lf2TE2LzO7x85uUPu8SKt3=OLx1iQKg@mail.gmail.com' \
--to=testtest_2005@ukr.net \
--cc=14789@debbugs.gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).