Ticket #1275 (new bug)

Opened 12 years ago

Last modified 11 years ago

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:


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")
    ok(1, "eq_num")

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


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


t_op_comp_t.patch Download (351 bytes) - added by mikehh 12 years ago.

Change History

Changed 12 years ago by mikehh

Changed 12 years ago by mikehh

I tested the the patch provided on on Ubuntu 9.10 i386 and Ubuntu 9.10 amd64 and with it the test passes with gcc/g++ both with and without --optimize.

If anyone else can test it to see if it causes any problems.

If I have no objections, I will apply the patch before the release tomorrow.

Changed 12 years ago by mikehh

  • version changed from 1.7.0 to trunk
  • component changed from none to testing

I have applied the patch (with some comments) in r42547

Changed 11 years ago by jkeenan

  • owner set to mikehh


Is this ticket closable? (Assigning to you for decision.)

Thank you very much.


Note: See TracTickets for help on using tickets.