|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34599 Accuracy of round() function affected by compiler optimizations (PHP 5.1 works)
Submitted: 2005-09-22 16:04 UTC Modified: 2005-12-24 02:13 UTC
Avg. Score:4.0 ± 1.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: osolo at wndtabs dot com Assigned:
Status: Wont fix Package: Math related
PHP Version: 4CVS-2005-09-26 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: osolo at wndtabs dot com
New email:
PHP Version: OS:


 [2005-09-22 16:04 UTC] osolo at wndtabs dot com
The round() function will return inconsistent results when PHP is compiled under certain Linux distro/CPU/compiler combinations.

For example, if when compiling PHP on Gentoo 1.12.0_pre6/cc 3.4.4/Pentium 4, we get:
  round(0.245,2) => 0.24
Instead of the expected 0.25.  

I've traced the problem to the PHP_ROUND_WITH_FUZZ macro in ext/standard/math.c.  This macro starts out as:

#define PHP_ROUND_WITH_FUZZ(val, places) { \ 
  double tmp_val=val, f = pow(10.0, (double) places); \

Changing the first line to:
  volatile double tmp_val=val; double f = pow(10.0, (double) places); \

I suspect the problem is that the optimizer is keeping tmp_val in a floating point register that has a difference precision than a C double.  Declaring it volatile keeps it in the variable and makes things more consisntant.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-22 16:18 UTC]
Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is read this:
Thank you for your interest in PHP.

 [2005-09-22 21:16 UTC] osolo at wndtabs dot com
The bug is **not** about limited precision of floating point numbers.

The bug report is about the optimizer causing the function to return different values.  The function should return the same value whether or not its compiled with -O2.  The proposed fix does in fact solve this problem.
 [2005-09-22 21:43 UTC]
See also bug #17772 which has some talk about optimizations and some other options.

 [2005-09-23 10:03 UTC]
Please try using this CVS snapshot:
For Windows:

And don't try to outsmart the configure with any CFLAGS or LDFLAGS of your own.

 [2005-09-26 17:59 UTC] osolo at wndtabs dot com
Sniper, you either have finely tuned searching skills or the memory of an elephant (or both).  It would appear that this is either a duplicate or very similar to the straggly named bug #17772.

As you requested, I tested the problem with following versions:

4.4.0 - Broken
5.0.5 - Broken
5.1 RC1 - Good
5.1 CVS - Good

I'm not sure what changed between 5.0.5 and 5.1 RC1 that could fix this problem.  Perhaps someone who's more familiar with the sources can shed some light.

Currently, I'm looking to solve this for 4.4.0 because upgrading to PHP5 is not an option for our project.

Thanks for all the help!
 [2005-09-26 18:07 UTC]
Please try using this CVS snapshot:
For Windows:

Just to be on the safe side..try the PHP 4 snapshot too.
 [2005-09-26 21:13 UTC] osolo at wndtabs dot com
Tested php-STABLE-200509261835; the bug is still there.
 [2005-12-24 02:13 UTC]
This is not critical bug and as it works fine with 5.1 -> wont  fix.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Apr 14 03:01:23 2021 UTC