> $a &= $a-- + $a;

That statements has two modifications to $a: the -- and the &=. PHP does not guarantee in what order those will happen.

https://en.wikipedia.org/wiki/Sequence_point

Hi,

Even if I decouple the two operations into two statements, the issue still exists. Also, for the robustness, correctness, and consistency of php, the outputs should be the same.

Test script:
----------------
<?php
function test() {
    $n = 0;
    $a = 0;
    while($a <= 0) {
        $a &= $a + $a;
        $a--;
        if (++$n > 59) die("bug\n");
    }
}
test();
?>

I assume you do *not* get the float-to-int deprecation warning when $n=58? PHP doesn't support bitwise AND with floats and will round them to ints, but that comes with branch prediction so -O2 may be running afoul of that.

And that there is the limit of my knowledge on this matter.

Yes, I noticed the warning. I'm just worried that shouldn't all compilers/optimizations emit consistent results even if it's an error?

I also tried gcc11 with -O0 and -O2, on which php emits the same results as clang13 -O2.

Casting very small floats to int may change the sign:
<https://3v4l.org/Ku5YH>.  I don't think this is particularly
related to clang, nor to branch prediction, but the different
behavior might rather be related to whether
ZEND_DVAL_TO_LVAL_CAST_OK is defined or not[1].  If it is defined,
we cast to zend_long, and for double values outside the range of
zend_long, the behavior is undefined.

On Windows, where ZEND_DVAL_TO_LVAL_CAST_OK is never defined,
zend_dval_to_lval_slow()[2] yields an erroneous result anyway.

[1] <https://github.com/php/php-src/blob/php-7.4.26/Zend/Zend.m4#L158-L187>
[2] <https://github.com/php/php-src/blob/php-7.4.26/Zend/zend_operators.c#L3268-L3280>

The 32bit implementation of zend_dval_to_lval_slow() has an
explicit comment[1] which says "we're going to make this number
positive".  I don't understand the reasoning, but apparently that
is a deliberate design decision.  Then again I don't understand
why we don't saturate[2].

[1] <https://github.com/php/php-src/blob/php-7.4.26/Zend/zend_operators.c#L3261-L3262>
[2] <https://github.com/php/php-src/commit/77566edbafb969e166239b3fbc929588c6630ee9>

Well, should have (also) read the fine manual[1]:

| If the float is beyond the boundaries of int (usually +/-
| 2.15e+9 = 2^31 on 32-bit platforms and +/- 9.22e+18 = 2^63 on
| 64-bit platforms), the result is undefined, since the float
| doesn't have enough precision to give an exact int result.

According to that, the reported issue is not a bug.  On the other
hand, it would allow us to change the behavior to something more
reasonable.

[1] <https://www.php.net/manual/en/language.types.integer.php#language.types.integer.casting.from-float>

When you see "bug" on the screen it indicates an incorrect decrement as it only uses -1, run this code.
In the past I have read but I have lost the ticket, it could also be linked to something else (maybe optimization).

Never break int 60
function test() {
    $n = 0;
    $a = 0;
    $break = false;;
    while($a <= 0) {
        //if($a !== 0)
        //$a = $a - (-1);
        $a &= $a + ($a);
        $a--;
        if (++$n > 59) {
        $break = true;
        break;
        }
    }
return array($a, $n, $break);
}
var_dump(test());

Expected Result:
Deprecated: Implicit conversion from float -1.8446743800977043E+19 to int loses precision in /in/iBpbI on line 10
array(3) {
  [0]=>
  int(135292502015)
  [1]=>
  int(59)
  [2]=>
  bool(false)
}

Break int 60 and error decrement always -1
function test() {
    $n = 0;
    $a = 0;
    $break = false;;
    while($a <= 0) {
        if($a !== 0)
        $a = $a - (-1);
        $a &= $a + ($a);
        //$a--;
        if (++$n > 59) {
        $break = true;
        break;
        }
    }
return array($a, $n, $break);
}
var_dump(test());
Expected -1 Result:
array(3) {
  [0]=>
  int(0)
  [1]=>
  int(60)
  [2]=>
  bool(true)
}
if don't use manual decrement and the same output for $a-- is to equal Expected -1 Result this bug.

As per my comment above[1], I'm closing this as not a bug, since
changing the behavior would require the RFC process[2], even
though the behavior is documented as being undefined.

[1] <https://bugs.php.net/bug.php?id=81627#1637152922>
[2] <https://wiki.php.net/rfc/howto>