petdance/scratch — Issue #1110: failure with eq_num op in t/op/comp.t with g++ 4.4.1 --optimized build
Author: petdance
Created: 2011-11-01 05:39:13+00:00
State: open
Labels: bug, Pri-normal, Sev-medium, testing

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).

Originally http://trac.parrot.org/parrot/ticket/1275