see the note on float precision on

http://www.php.net/manual/en/language.types.float.php

No, 

This is a platform specific build/optimization issue not a float precision "bogus bug".  

Compile ext/standard/math.c without optimization i.e.
with -O0 instead of -O2, and the bug vanishes:

gcc -I. -I/home/george/php-4.2.1/ext/standard -I/home/george/php-4.2.1/main -I/home/george/php-4.2.1 -I/home/george/php-4.2.1/Zend -I/home/george/php-4.2.1/ext/mysql/libmysql -I/home/george/php-4.2.1/ext/xml/expat  -I/home/george/php-4.2.1/TSRM -g -O0  -c math.c && touch math.lo

(php 4.1.2 i386-pc-linux-gnu Debian Linux test 2.2.18pre21)

I believe BSD always works. 

For an even simpler test case, try round(0.35,1);

George

So it's rather Makefile issue? Or it shall be reported to Debian package maintainer then?

Switching off inline maths, (-D__NO_INLINE_MATHS), but leaving optimisation (-02), also solves this problem.

My guess as to what is going on is:

With inline maths, the value used on the floor() in round is coming straight from the fpu's register, not from memory. The register is wider than a double and contains spurious precision left over from the previous multiply, so the floor fp operation is carried out on the "wrong" number.  Without inline maths, the library floor() function is called so the operand comes out of the register and back into double format. 

This fits in with the observation that inserting trace or other code between the multiply and floor also solves the problem. 

If I'm right, the simple solution is to switch off in line maths, i.e. -D__NO_INLINE_MATHS.  For safety, this might need to be a general option across all compiles on Intel platforms. 

I'm going to try checking my diagnosis with a specialist newsgroup....


George Whiffen

I checked the diagnosis on comp.lang.c and it's definitely a problem with values from the register.  We don't need -D__NO_MATH_INLINES,  -ffloat-store on the compile works fine.