Edit report at https://bugs.php.net/bug.php?id=64142&edit=1
ID: 64142
Updated by: remi@php.net
Reported by: remi@php.net
Summary: dval to lval different behavior on ppc64
-Status: Assigned
+Status: Closed
Type: Bug
Package: *General Issues
Operating System: GNU/Linux
PHP Version: 5.4.11
Assigned To: remi
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of remi
Revision: http://git.php.net/?p=php-src.git;a=commit;h=e67a2b9e471a7bc0b774b9056bb38745b7187969
Log: Fixed bug #64142 (dval to lval different behavior on ppc64)
Previous Comments:
------------------------------------------------------------------------
[2013-02-05 14:58:35] remi@php.net
@cataphract see my latest message on php-cvs ML.
Really strange. C Test (with -O2) give the same result on x86_64 and ppc64 and seems to prove the
fix is not needed.
No I need to understand why it improves the PHP result.
I can keep the test builder for some time, so will investigate on this...
------------------------------------------------------------------------
[2013-02-05 12:37:07] cataphract@php.net
BTW, that's with optimization turned off. If I pass -O3 to gcc , it's still able to figure
out it doesn't need to cast anything and the output is -9223372036854775808.
In any case, we should get to the bottom of this. I very much doubt the patch is wrong, but if we
figure out the underling cause we may find out the problem is larger.
------------------------------------------------------------------------
[2013-02-05 12:32:35] cataphract@php.net
> (long)(double)9223372036854775807-1 = 9223372036854775807
Ah sorry, I read that wrong. It can't obviously be rounding down, because the result seems
larger; you're subtracting one here when you're adding 1 on top... The part about the
closes doubles is wrong too, they're already spaced by 1024 by then.
In any case, your explanation in the commit seems both irrelevant and wrong. AS to the wrong part,
in x86_64:
printf("%ld\n",((long)(double)9223372036854775807)+1);
double dd = 9223372036854775807;
printf("%ld\n", ((long)dd) + 1);
gives
-9223372036854775808
-9223372036854775807
So the -9223372036854775808 result is just an artifact of the compiler doing away with the casts
completely.
------------------------------------------------------------------------
[2013-02-05 11:05:02] cataphract@php.net
The commit message says:
> On x86_64:> (long)(double)9223372036854775807+1 = -9223372036854775808> On ppc64> (long)(double)9223372036854775807-1 = 9223372036854775807
How much is (long)(double)0x7fffffffffffffffL in that arch? Is it 0x7ffffffffffffffeL ?
The closest doubles near 0x7fffffffffffffff are 0x8000000000000000 and 0x7ffffffffffffffe. So
basically ppp64 rounds down while x64 rounds up? If that's the case, there's nothing to
"fix" in the code; you'll presumably get this behavior in a lot of other places, not
just when casting LONG_MAX to double.
But in any case, I don't see how that is relevant to the patch. The patch changes a (long)dval
cast to (long)(unsigned long)dval cast, which is a double-to-long cast, not a long-to-double cast.
------------------------------------------------------------------------
[2013-02-05 07:19:18] remi@php.net
Automatic comment on behalf of remi
Revision: http://git.php.net/?p=php-src.git;a=commit;h=6533094d9e4d0c85044a170d9fad9a3986a68675
Log: Fixed bug #64142 (dval to lval different behavior on ppc64)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64142--
Edit this bug report at https://bugs.php.net/bug.php?id=64142&edit=1