P.S. I would look into this further but have no idea where to look for the problem or how to debug PHP internal's. Looking for some input and happy to help with testing in any way I can.

"two variables that have integers get summed and return a float."

Yes - this is the defined behaviour for when an operation occurs and the result is no longer representable as an integer type. e.g.

<?php

$x = PHP_INT_MAX;
$x += 1;
var_dump($x);

?>

Will say that $x is a float value. Or to quote from the manual - http://php.net/manual/en/language.types.integer.php

"If PHP encounters a number beyond the bounds of the integer type, it will be interpreted as a float instead. Also, an operation which results in a number beyond the bounds of the integer type will return a float instead."

If you think the conversion from int to float is occurring inappropriately, please can you provide a simple reproduction case?

Sure, it's small values. Real code was $i=68 and $l=71, IIRC. You can see the test case on the Gist I posted in the description on the bug. There it returns a float with smaller integers. What should have been 10 or so becomes 9.xx*10^18, something like that.

As I mentioned, all code runs fine in i686 but "blows up" on x32 ABI (which is quite useful no virtualized servers).

I don't think we currently really support the x32 ABI. You're likely tripping over some inline assembly that is not properly #if'd.

Managed to fix some stuff, though they're mostly hacks to always run i386 code. 
Current problem is most of the Zend operators are passing 64bit instructions to x32 PHP, so I just #if'd them to add ILP32 checks to the i386 assembly instead. I think this is mostly correct (not optimized) but x86-64 assembly has the same issue with these x32 changes: it is still using x87 instead of the faster SSE2, as it should on x86-64 capable CPUs. 

From looking at the current code, I didn't understand why the FPU is being used to calculate integer operations (this shouldn't be faster).

I also think there might be problems with the 'safe_address' function in 'Zend/zend_alloc.c', as it has LP_SUFF defined for the 'mul' instruction, as it should, but uses both 'add/adc'. My understanding from the manuals is that this is correct if the operands to the instruction are 32bit for x32, then all will be ok, while 64bit operands will execute as 64bit. Still, if this is a mixup of AT&T and Intel syntax for opcodes, it should probably be unified and checked for correct word size on the parameters.

Below are the results of 'make test' before and after the patch submitted, which shows no regressions. The test case I submitted also passes now.

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #24054 (Assignment operator *= broken) [tests/lang/bug24054.phpt]
Test >= operator : max int 32bit range [tests/lang/operators/operator_gt_or_equal_variation.phpt]
Test > operator : max int 32bit range [tests/lang/operators/operator_gt_variation.phpt]
Test <= operator : max int 32bit range [tests/lang/operators/operator_lt_or_equal_variation.phpt]
Test < operator : max int 32bit range [tests/lang/operators/operator_lt_variation.phpt]
Bug #45877 (Array key '2147483647' left as string) [Zend/tests/bug45877.phpt]
decrementing different variables [Zend/tests/decrement_001.phpt]
incrementing different variables [Zend/tests/increment_001.phpt]
Bug #41523 (strtotime('0000-00-00 00:00:00') is parsed as 1999-11-30) (32 bit) [ext/date/tests/bug41523.phpt]
Test getdate() function : usage variation - Passing high positive and negative float values to timestamp. [ext/date/tests/getdate_variation7.phpt]
Test localtime() function : usage variation - Passing higher positive and negetive float values to timestamp. [ext/date/tests/localtime_variation3.phpt]
Test array_sum() [ext/standard/tests/array/array_sum.phpt]
Bug #65304 (Use of max int in array_sum) [ext/standard/tests/array/bug65304.phpt]
Simple math tests [ext/standard/tests/math/abs.phpt]
Various pow() tests [ext/standard/tests/math/pow.phpt]
Simple math tests [ext/standard/tests/math/round.phpt]
Bug #64146 (serialize incorrectly saving objects when they are cloned) [ext/standard/tests/serialize/bug64146.phpt]
=====================================================================

Patched:

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #41523 (strtotime('0000-00-00 00:00:00') is parsed as 1999-11-30) (32 bit) [ext/date/tests/bug41523.phpt]
Test getdate() function : usage variation - Passing high positive and negative float values to timestamp. [ext/date/tests/getdate_variation7.phpt]
Test localtime() function : usage variation - Passing higher positive and negetive float values to timestamp. [ext/date/tests/localtime_variation3.phpt]
Bug #64146 (serialize incorrectly saving objects when they are cloned) [ext/standard/tests/serialize/bug64146.phpt]
=====================================================================

Forgot to mention I'll be looking at the rest of the tests to see if I can fix them. Pointers to the Date issues would be useful.

For the record, PHP 7 is now mostly working on x32 as well. I've landed some tweaks in https://github.com/php/php-src/commit/f3dde29394831c59fc927bd5e7a7800a3fbe8519 which make nearly all tests pass - there's two or three failures left due to wrong size_t/zend_long usage resulting in overflows.

I went for making PHP integers 64bit - this integrates very nicely with how zend_long is currently used (all our assembly is still correct) and I think this is what PHP programmers would want to have. But not totally sure if this is the right choice.

Hey there,

Had been looking at the date bugs I posted before from the test suite but everything seemed fine where I looked. Today I tried the zend operators patch on 5.6.13 and those are gone. Tests below configured with:

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #53437 DateInterval unserialize bad data, 32 bit [ext/date/tests/bug53437_var3.phpt]
Bug #64146 (serialize incorrectly saving objects when they are cloned) [ext/standard/tests/serialize/bug64146.phpt]
=====================================================================
WARNED TEST SUMMARY
---------------------------------------------------------------------
Bug #70172 - Use After Free Vulnerability in unserialize()
[ext/standard/tests/serialize/bug70172.phpt] (warn: XFAIL section but test passes)
=====================================================================

Compiled on i686 to check for differences and the i686 versions shows one more failed test but is otherwise the same. I imagine this is due to some fix related to x86-64.

=====================================================================
Bug #41655 (open_basedir bypass via glob()) 1/2 [ext/standard/tests/file/bug41655_1.phpt]
chroot() [ext/standard/tests/file/chroot_001.phpt]
Test glob() function: ensure no platform difference, variation 3 [ext/standard/tests/file/glob_variation5.phpt]
=====================================================================

At this time, the zend_operators patch seems to work for these versions, so could it possibly be merged?

Glad to hear PHP7 is looking good on x32! As for the integer size, it would be better to be 32bit to be consistent with C and be able to make use of both of 32 and 64bit registers, which is one of the performance benefits. My understanding is that PHP only supports one integer size, so being 64bit is probably better if the programmer can't choose.

Hey there,

Been trying x32 on PHP 7 and it has various bugs that keep it from working. I've been trying to fix some stuff but still have problems with PHAR during compilation, which seems to stem from a memcpy().

Would it be possible to merge this updated patch below? I backported some changes from the assembly in PHP 7 that seems to fix a movb that was malformed. It works on both 5.5.37 and 5.6.23.

There are some 32-bit tests that fail because time values are expected to overflow and don't, which haven't tracked but may be related to x32 having 64-bit time values.

https://github.com/tmarques/overlay_x32-abi/raw/master/dev-lang/php/files/zend_operators_x32-5.patch

What is the status of the actively supported PHP versions[1]
regarding x32 ABI?  If anything would need to be fixed, I suggest
you submit a pull request[2].

[1] <https://www.php.net/supported-versions.php>
[2] <https://github.com/php/php-src/pulls>

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.