Edit report at https://bugs.php.net/bug.php?id=64142&edit=1

 ID:                 64142
 Updated by:         cataphr...@php.net
 Reported by:        r...@php.net
 Summary:            dval to lval different behavior on ppc64
 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:

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.


Previous Comments:
------------------------------------------------------------------------
[2013-02-05 12:32:35] cataphr...@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] cataphr...@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] r...@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)

------------------------------------------------------------------------
[2013-02-05 01:16:05] ras...@php.net

You should be able to commit it now

------------------------------------------------------------------------
[2013-02-04 14:32:57] r...@php.net

It seems I cannot commit this fix (You have insufficient Karma!)

Notice:
No regression detection on x86_64 (no failed test)
On ppc64 we now have only 16 failed tests (instead of 25)

------------------------------------------------------------------------


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

Reply via email to