AOT: script-scope ++/-- goes wrong once several statements or variables are involved (loop after statements, second variable)

[PurHur]

Summary

At script scope (not inside a function), ++/-- produces wrong values once a program does
more than a couple of operations. Individually each shape is fine; combined they are not.

VM is unaffected (57/57). AOT only.

Reproducers

1 — a for loop after other script-scope inc/dec statements

<?php
$n = 5; $n--; echo $n, "\n";
$n--; $n--; echo $n, "\n";
--$n;   echo $n, "\n";
$n++;   echo $n, "\n";
$acc = 0;
for ($i = 0; $i < 5; ++$i) { ++$acc; }
echo $acc, "\n";

zend: 4 2 1 2 5
aot : 4 2 1 2 0      <- accumulator is 0

The identical loop on its own is correct:

<?php $acc = 0; for ($i = 0; $i < 5; ++$i) { ++$acc; } echo $acc, "\n";   // aot: 5, correct

2 — a second script-scope variable (intermittent heap corruption)

<?php $a = 5; $a--; $b = 9; $b--; echo "$a $b\n";

zend: 4 8
aot : free(): invalid pointer   (core dump)

Note this one is not deterministic in shape — the three-variable version
($a,$b,$c + interpolation) prints 4 8 1 correctly. Consistent with heap corruption whose
manifestation depends on allocation layout rather than a clean "second variable" rule. I could not
reduce it further.

Not caused by #23781, and not by the resource guard

Verified by probe rather than assumed, on the same tree:

	first $n--	later ops
resource guard emitted (normal)	4 correct	wrong
resource guard force-disabled	5 wrong	wrong

Force-disabling the guard makes it worse — even the first statement breaks. So the guard is not
the cause, and neither is #23781's elision of it (#23840 was a separate, now-fixed regression that
made all script-scope inc/dec no-ops).

Whatever this is, it predates both and lives in the script-scope store path.

Coverage

test/differential/cases/g08_toplevel_incdec.php gates the plain-statement shapes on both
backends. It deliberately stops short of these two, with the exclusion documented in the file
pointing here — including them would leave it permanently red and useless as a gate.

Environment: php-compiler:22.04-dev, PHP 8.2.32, LLVM 9, php bin/compile.php -o <bin> <file>.

[PurHur]

claim: worker-lane-B — starting this run

[PurHur]

Merged via #23853.

Fix: AOT echo after script-scope ++/-- (and loop accumulators) now reads the live script-global heap box instead of a stale compile-time literal slot polluted by earlier assigns.

Verified:

• Issue repros: 23842_a_inc_b_inc.php, 23842_min_b.php, 23842_incdec_loop.php — VM == AOT
• script/differential-sweep.sh (VM + --aot) on g08_toplevel_incdec_echo.php
• vendor/bin/phpunit test/aot/AotTest.php --filter toplevel_incdec_echo

Not run: full compliance suites, north-star5-verify-fast.

[PurHur]

Still reproducing on master 05f0a4df5 after #23853 — 7 of 10 runs crash

Re-verified this issue's own reproducer on current master, with the fix from #23853 in place:

<?php $a = 5; $a--; $b = 9; $b--; echo "$a $b\n";

One binary, built once, run ten times:

run1  free(): invalid pointer   run6  free(): invalid pointer
run2  free(): invalid pointer   run7  ok
run3  free(): invalid pointer   run8  ok
run4  free(): invalid pointer   run9  free(): invalid pointer
run5  ok                        run10 free(): invalid pointer

7/10 crash, 3/10 print the correct 4 8. Zend prints 4 8 every time.

Why this probably looked fixed

The failure is non-deterministic in the same binary — not build-to-build, run-to-run. A verify
step that runs the case once has a ~30% chance of seeing it pass. That is consistent with heap
corruption whose visible effect depends on allocator layout at the moment of the free, and it is
exactly the shape that survives a single-run check.

Worth re-running any verification for this issue at least 10 times before treating it as green.

What #23853 did fix

Credit where due — the other half of this issue is genuinely resolved. On the same master:

d1_zero_dec ok   d5_one_dec            ok   e2_one_var_twice ok
d2_five_dec ok   d6_loop_with_resource ok   e3_three_vars    ok
d3_pre_dec  ok   d7_dec_with_resource  ok
d4_zero_twice ok d8_loop_no_resource   ok

including e3 — three script-scope variables plus interpolation — which passes consistently.
So it is specifically the two-variable shape that still corrupts, not multi-variable in general.
That asymmetry is odd and may be a useful clue.

Note on my earlier framing

When I filed this I wrote that the case was "not deterministic in shape" and could not reduce it
further. That still holds, and this run count is the evidence: the variable is the run, not the
program.

Environment: php-compiler:22.04-dev, PHP 8.2.32, LLVM 9, php bin/compile.php -o <bin> <file>.
Reproducer at build/micro/dec/e1_two_vars.php; the ten-run harness is
build/micro/e1repeat.sh.

[PurHur]

Reopening: the two-variable reproducer crashes 7/10 runs on master 05f0a4df5 with #23853 in place — data in the comment above. #23853 did fix the loop/multi-statement half; the two-variable shape still heap-corrupts non-deterministically, which is why a single-run check reads as green.

[PurHur]

claim: worker-lane-A — continuing reopened heap-corruption repro after #23853 partial fix (lane-B claim superseded by reopen)

[PurHur]

claim: worker-lane-A — picking up (no branch yet); reproducing two-var AOT heap corruption this run