Ticket #1275 (new bug)
failure with eq_num op in t/op/comp.t with g++ 4.4.1 --optimized build
Reported by: | mikehh | Owned by: | mikehh |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | testing | Version: | trunk |
Severity: | medium | Keywords: | |
Cc: | Language: | ||
Patch status: | Platform: |
Description
I switched to Ubuntu 9.10 i386 and eventually got parrot to build with g++ ver 4.4.1 (about two weeks ago) I started getting an error with t/op/comp.t on an optimized build with g++ on i386 - the error did not effect the build without --optimize and the gcc build passes the test both with and without --optimize. The test also passed with all four options on amd64, both on Ubuntu 9.04 amd64 and Ubuntu 9.10 amd64 (gcc/g++ 4.4.1 and 4.3.4) respectively) - I had upgraded my Ubuntu 9.04 i386 to Ubuntu 9.10 i386 so could no longer test there. NotFound++ did test on that platform and it passed, however when he installed Ubuntu 9.10 i386 on his laptop he got the same results with g++ and --optimize.
see comments by NotFound and mikehh on TT #1176.
I was working on converting the test to .pir from .pasm when bubaflub++ posted a patch to do this in TT #1269 - I applied this in r42518 - the test is now sub-test 17
I was on amd64 at the time, but when I re-booted to i386 the test still gave a failure with the eq_num op on i386 with an --optimize build with g++. (PASSes on all my other platform/options.)
Specifically the code:
.sub test_eq_num new $P0, 'Float' set $P0, -1.2 new $P1, 'String' set $P1, "-1.2" eq_num $P0, $P1, OK ok(0, "not eq_num") .return() OK: ok(1, "eq_num") .end
the eq_num $P0, $P1, OK does not take the OK branch
if I change to set P1, "-1.2000000000" the test passes (with all options on i386), fewer zeros still fail (more ok).
if I set POW to powl (as per TT #1176) the test also passes (with $P1 as "-1.2")
Analysis
What is happening here is that with g++ 4.4.1 (with --optimize) actually uses higher precision in intermediate code (as allowed by the standard)
On further consideration I decided that although this is related to TT #1176 it is actually a different problem in that as we are not specifying use of long double POW would be set to pow rather than powl in this case.
I have serious doubts as to the validity of using the eq_num op in comparing float to string, certainly when using binary floats as opposed to decimal floats. see http://speleotrove.com/decimal/
excuse the excessive verbosity in the post, but I felt explanations were necessary, (and I cut out quite a bit)
We can get the test to pass using the set P1, "-1.2000000000" as it also passes with the normally passing tests (at least on i386, will check on amd64 in a bit).