#34599 [Opn->Fbk]: Accuracy of round() function affected by compiler optimizations

ID: 34599 Updated by: sniper@php.net Reported By: osolo at wndtabs dot com -Status: Open +Status: Feedback Bug Type: Math related Operating System: Linux PHP Version: 4.4.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip And don't try to outsmart the configure with any CFLAGS or LDFLAGS of your own. Previous Comments: ------------------------------------------------------------------------ [2005-09-22 21:43:41] sniper@php.net See also bug #17772 which has some talk about optimizations and some other options. ------------------------------------------------------------------------ [2005-09-22 21:16:05] 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 16:18:52] tony2001@php.net 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: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. ------------------------------------------------------------------------ [2005-09-22 16:04:20] osolo at wndtabs dot com Description: ------------ 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. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=34599&edit=1