Red Hat Bugzilla – Bug 145282
Script Returns Incorrect Values
Last modified: 2007-11-30 17:10:58 EST
Description of problem: PHP code is returning incorrect values but ONLY with Fedora (only tried FC3 so can't say if 1 and 2 are also affected) Bascially, the code is not returning the correct values, it seems as though bit shifting is out of sync somehow. Version-Release number of selected component (if applicable): I'm using Kernel 2.6.10-1.741_FC3smp - occurs with PHP4.3.9, PHP4.3.10 and the latest PHP4.3.11-DEV - Compiled PHP from source and RPM's How reproducible: Run a small snippet of PHP found here: http://www.milonic.com/bugreports/php_fc3.php Steps to Reproduce: 1. 2. 3. Actual results: 251066875, 1541925888, -402039036 Expected results: 251066875,-1654377486,-1500734959 Additional info: This problem has also been reported to the PHP team http://bugs.php.net/bug.php?id=31569 Thought i'd report it to you as we are not sure yet where the problem lies. The code used to generate the actual values can be executed almost identically in both PHP and JavaScript. Any OS other than FC3 will return the correct values. Have tried it with Redhat7, Redhat9 and FreeBSD 5.3 all of which are fine.
Are you getting the same erroneous results when compiling PHP from an upstream CVS snapshot? see also bug 143514 for different behaviour of "z = hex2dec(80000000)"
Unfortunately yes I am getting the same results. https://bugzilla.redhat.com/beta/show_bug.cgishow_bug.cgi?id=143514 is not a problem for me, I get the expected results with the latest version of PHP. Narrowed the problem down to this: <? $b = 251066875; $a = -3111919630; echo $b ^= ($a<<10); ?> Fedora 3 echos: 251066875 (wrong) All other OS's echo: 25768443 (correct)
As per upstream: $a=-3111919630; echo $b ^= ($a<<10); 1. -3111919630 cannot be represented in a 32-bit long, so it's stored in a double 2. "$a << 10" is executed using (long) integer arithmetic, so $a is converted to a long here 3. the Zend macro which converts double to long used to be miscompiled by GCC, but this was fixed in the FC3 gcc.