Em 2013-02-20 9:15, Stas Malyshev escreveu:
Hi!
Also, I'm not sure I understand what 64-bit test is supposed to
return
and why - why negative number is converted to positive one? What
exactly
this change is supposed to improve?
The least significant bytes are preserved. Take int(-2056257536
Hi!
>> Also, I'm not sure I understand what 64-bit test is supposed to return
>> and why - why negative number is converted to positive one? What exactly
>> this change is supposed to improve?
>
> The least significant bytes are preserved. Take int(-2056257536) and
> int(2943463994971652096):
>
On Tue, 19 Feb 2013 03:07:37 +0100, Stas Malyshev
wrote:
If no one objects, I'll merge this into 5.5 and master:
https://github.com/cataphract/php-src/compare/dval_to_lval
Maybe add UNEXPECTED around the if condition? Since it's marked as
zend_always_inline I imagine it's supposed to be pe
Hi!
> If no one objects, I'll merge this into 5.5 and master:
>
> https://github.com/cataphract/php-src/compare/dval_to_lval
Maybe add UNEXPECTED around the if condition? Since it's marked as
zend_always_inline I imagine it's supposed to be performance-sensitive...
Also, skip comments in tests
On Mon, 11 Feb 2013 08:05:43 +0100, Stas Malyshev
wrote:
This was I was afraid. That bug was just the tip of the iceberg. I
suggest we do change the the > operator to >= like you proposed,
I will do it later today.
>= may be fine, but I am concerned about fmod change for 5.4. If we do
it,
If you find some interests on looking at the remaining ppc64 issues,
I have uploaded the 16 failed tests results
http://blog.famillecollet.com/public/reports/failures-5.4.11-ppc64.tgz
(this is 5.4.11, but with ppc64 patches applied, 46 failures before)
Remi.
--
PHP Internals - PHP Runtime Deve
On Mon, 11 Feb 2013 09:43:36 +0100, Remi Collet
wrote:
Le 10/02/2013 20:27, Gustavo Lopes a écrit :
Any reservations?
For which values ? Outside LONG_MIN .. ULONG_MAX ?
It should be valid for the whole domain, but for performance reasons it
would be better to limit it to values at lea
Le 10/02/2013 20:27, Gustavo Lopes a écrit :
> Any reservations?
Do we really want/need to change the current behavior.
Cast from double, outside of integer range, result in a fix value.
The only problem is that the value is not the same on all arch.
x86_64 always return 0x8000...
ppc64 retur
Hi!
>> This was I was afraid. That bug was just the tip of the iceberg. I
>> suggest we do change the the > operator to >= like you proposed,
>
> I will do it later today.
>= may be fine, but I am concerned about fmod change for 5.4. If we do
it, I'm afraid we may change some scenario, so I'd p
Le 10/02/2013 20:27, Gustavo Lopes a écrit :
> This was I was afraid. That bug was just the tip of the iceberg. I
> suggest we do change the the > operator to >= like you proposed,
I will do it later today.
> but also that we add the fmod call. The code I gave earlier had a bug btw,
> as fmod
On Sun, 10 Feb 2013 16:19:46 +0100, Remi Collet
wrote:
Le 10/02/2013 15:58, Gustavo Lopes a écrit :
Can you test this program on ppc64:
$ gcc -O3 -lm conv.c && ./a.out 9223372036854775808
-9223372036854775808 -9223372036854775808
$ gcc -O3 -lm conv.c && ./a.out 4e21
-2943463994972700672
Le 10/02/2013 15:58, Gustavo Lopes a écrit :
> If we want to eliminate the undefined behavior, we should do (on archs
> with 64-bit longs):
>
> (long)(unsigned long)(fmod(d, pow(2., 64.)))
>
> Can you test this program on ppc64:
$ gcc -O3 -lm conv.c && ./a.out 9223372036854775808
-9223372036854
On Sun, 10 Feb 2013 12:00:01 +0100, Gustavo Lopes
wrote:
My concern is that we may also have different behavior when we go
outside the unsigned long range.
As to whether ppc64 or x86_64 is correct when casting (double)LONG_MAX
to a signed long, the answer is this that since the double is
On 10/02/13 06:50, Stas Malyshev wrote:
isn't the case with visualC, and PHP internal data structures compiled
with visualC and gcc are significantly different; for example hash keys
are 32 bits long on Windows and 64bits on *nix. Why aren't they 32bits,
Yes, they are different, because long si
On Sun, 10 Feb 2013 09:35:41 +0100, Stas Malyshev
wrote:
So, looks like on ppc64 double->long conversion works differently than
on x86_64. Maybe best solution would be to make the patch with ifdef for
ppc64 so that it would do the same as Intel... Though I'm not sure if
somebody on this platf
hi Terry.
On Sun, Feb 10, 2013 at 12:02 AM, Terry Ellison wrote:
> On 09/02/13 15:47, Pierre Joye wrote:
>
> hi Remi
>
> On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet wrote:
>
> About
> http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
> (For now, I have rev
Hi!
> On x86_64 (so, with or without -O2)
>
>
> $ gcc -O2 -Wall math2.c -o math2 && ./math2 9223372036854775807
> double=9223372036854775808
> signed=8000
> unsigned=8000
>
>
> On ppc64
>
> $ gcc -O2 -Wall math2.c -o math2 && ./math2 9223372036854775807
> double=
One more test (to get rid of compiler optimization)
int main (int argc, char *argv[]) {
double d;
if (argc>1 && sscanf(argv[1], "%lg", &d)) {
printf(" double=%.20lg\n", d);
printf(" signed=%lx\n", (long)d);
printf(
Le 10/02/2013 05:54, Stas Malyshev a écrit :
> Hi!
>
>> About
>> http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
>> (For now, I have reverted this fix)
>>
>> Here some explanations.
>>
>> LONG_MAX is 9223372036854775807 (0x7fff)
>> double repre
Hi!
> Stan, you are right to correct me. Sorry. However, I still feel that
> the implicit assumption is that sizeof(long) == 2*sizeof(int) and this
I'm not sure where this assumption exists. Could you be more specific?
PHP uses long for most integer values, and int for some internal things
and
On 10/02/13 03:25, Stas Malyshev wrote:
these onto the appropriate visualC / gcc types. As far as I can see,
PHP doesn't and seems to use long and int almost interchangeably which
PHP indeed does not use fixed-size types in zvals, etc. but it
definitely does not "use long and int almost inter
Hi!
> About
> http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
> (For now, I have reverted this fix)
>
> Here some explanations.
>
> LONG_MAX is 9223372036854775807 (0x7fff)
> double representation of LONG_MAX is 9223372036854775808
I see wha
Hi!
> these onto the appropriate visualC / gcc types. As far as I can see,
> PHP doesn't and seems to use long and int almost interchangeably which
PHP indeed does not use fixed-size types in zvals, etc. but it
definitely does not "use long and int almost interchangeably". In almost
any place
On 09/02/13 15:47, Pierre Joye wrote:
hi Remi
On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet wrote:
About
http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
(For now, I have reverted this fix)
Here some explanations.
LONG_MAX is 9223372036854775807 (0x7fff
hi Remi
On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet wrote:
> About
> http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
> (For now, I have reverted this fix)
>
> Here some explanations.
>
> LONG_MAX is 9223372036854775807 (0x7fff)
> double repres
Le 09/02/2013 16:10, Remi Collet a écrit :
> http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
Also see https://bugs.php.net/bug.php?id=64142
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
About
http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
(For now, I have reverted this fix)
Here some explanations.
LONG_MAX is 9223372036854775807 (0x7fff)
double representation of LONG_MAX is 9223372036854775808
(d > LONG_MAX) is evaluated in
27 matches
Mail list logo
