Fix GH-22206: avoid musttail in zend_runtime_jit() in the tail-call VM

[lazerg]

With --disable-gcc-global-regs and a compiler that supports preserve_none, opcache is built with ZEND_VM_KIND_TAILCALL, where ZEND_OPCODE_RETURN() expands to a guaranteed tail call. zend_runtime_jit() does its work inside zend_try(), which uses setjmp(), and GCC 16 rejects that combination with "cannot tail-call: caller uses setjmp".

GH-22320 fixed the --enable-gcc-global-regs side of the same report. Here the tail call isn't needed: zend_runtime_jit() is a cold one-shot JIT trigger rather than a hot VM handler, so a plain call works and the returned opline still goes back to the VM loop as before.

Checked with GCC 16.1.0: a --disable-gcc-global-regs build fails on ext/opcache/jit/zend_jit.lo before the change and compiles after it. ext/opcache and Zend tests pass on a tail-call VM build.

Fixes GH-22206

[arnaud-lb]

This is not really a supported configuration, and even with this fix the build fails on my machine with errors related to musttail:

Zend/zend_vm_execute.h: In function 'ZEND_RETURN_BY_REF_SPEC_OBSERVER_TAILCALL_HANDLER':
Zend/zend_vm_execute.h:53688:66: error: address of automatic variable 'observer_retval' can escape to 'musttail' call [-Werror=maybe-musttail-local-addr]
53688 | # define ZEND_VM_CONTINUE()                    ZEND_VM_TAIL_CALL(opline->handler(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU))
      |                                                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Zend/zend_vm_execute.h:53687:69: note: in definition of macro 'ZEND_VM_TAIL_CALL'
53687 | # define ZEND_VM_TAIL_CALL(call)               ZEND_MUSTTAIL return call
      |                                                                     ^~~~
Zend/zend_vm_execute.h:53695:91: note: in expansion of macro 'ZEND_VM_CONTINUE'
53695 | # define ZEND_VM_DISPATCH_TO_LEAVE_HELPER(helper) opline = &call_leave_op; SAVE_OPLINE(); ZEND_VM_CONTINUE()
      |                                                                                           ^~~~~~~~~~~~~~~~
Zend/zend_vm_execute.h:57867:9: note: in expansion of macro 'ZEND_VM_DISPATCH_TO_LEAVE_HELPER'
57867 |         ZEND_VM_DISPATCH_TO_LEAVE_HELPER(zend_leave_helper_SPEC_TAILCALL);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

GCC's musttail is stricter than Clang, so we can not support the TAILCALL VM on GCC yet.

Normally the TAILCALL VM is not selected on GCC due to global regs supports, but --disable-gcc-global-regs breaks this. Maybe we should explicitly enable the TAILCALL VM only on Clang.

[lazerg]

I reproduced this. On macOS/aarch64 with GCC 16.1 and --disable-gcc-global-regs, compiling Zend/zend_execute.c produces 124 -Wmaybe-musttail-local-addr warnings, spread over 66 generated *_TAILCALL_HANDLER functions and 13 distinct locals:

hval (34), obj (21), _cache_slot (18), retval (12), error (9), key_tmp (8), new_expr (7), c (5), count (3), tmp (3), observer_retval (2), len (1), ctx (1).

Your build stopped on observer_retval because you compile with --enable-werror. Without -Werror the file still compiles and prints all 124.

So observer_retval is not a special case. The handler passes return_value, which can be &observer_retval, to zend_observer_fcall_end(). That is an opaque call, so GCC cannot prove an observer does not keep the pointer. Then ZEND_VM_DISPATCH_TO_LEAVE_HELPER musttails away and the frame is gone. Every other warning has the same shape: the address of a local reaches a non-inlined callee, and the handler ends in ZEND_VM_CONTINUE().

Two more things I checked:

• All 124 are the "maybe" variant. Zero definite -Wmusttail-local-addr.
• GCC does not drop the tail call when it warns. Minimal case:

void sink(int *p);
int next(void);
int f(void) {
    int local = 42;
    sink(&local);
    [[gnu::musttail]] return next();
}

compiles to bl _sink followed by b _next on aarch64. The frame is released while the pointer may still be live, so -Wno-maybe-musttail-local-addr would only hide the hazard.

I agree with your conclusion. Fixing observer_retval would just move the first failure to hval, then to the next one. The selection lives in the generated Zend/zend_vm_opcodes.h:

#elif defined(HAVE_MUSTTAIL) && defined(HAVE_PRESERVE_NONE) && (defined(__x86_64__) || defined(__aarch64__))
# define ZEND_VM_KIND		ZEND_VM_KIND_TAILCALL

emitted by Zend/zend_vm_gen.php:2526, so adding defined(__clang__) is a small change: the generator line plus the regenerated header.

I did not do it here for two reasons. It is a support decision that is yours to make. And it makes this PR unnecessary: the setjmp conflict in zend_runtime_jit() only happens on GCC, so gating the TAILCALL VM to Clang removes that failure too. I can prepare the gate, either as another commit on this PR or as a separate one, and close this. Tell me which you prefer.

One side note. GCC 16.1 on darwin/aarch64 also ICEs on the TAILCALL build, a segfault in the vartrack RTL pass, in both Zend/zend_execute.c and ext/opcache/jit/zend_jit_vm_helpers.c. I had to compile with -g0 to get past it and collect the warnings above. That looks like a separate GCC bug, but it is one more sign that GCC and the TAILCALL VM are not close to working together.

[arnaud-lb]

I didn't realize that this was a warning and not a hard error, thank you for pointing this. Maybe this was not the case before? I'm not sure.

So we we could add -Wno-maybe-musttail-local-addr in GCC builds.

But given your last paragraph I would be in favor of adding defined(__clang__) in the guard of # define ZEND_VM_KIND ZEND_VM_KIND_TAILCALL for now.

[lazerg]

Sure, that's an easy change on my end, one line in the generator plus regenerating zend_vm_opcodes.h. Only thing is it turns off the tail-call VM for every GCC build, not just this bug, so might be worth another maintainer weighing in before I push it. Let me know and I'll have it ready.

[arnaud-lb]

The TAILCALL VM is only really supported on Clang, and as we have found it doesn't build on GCC due to multiple factors, so disabling on non-Clang compilers is fine.

[lazerg]

Done, pushed the guard. GCC now falls back to the call VM, Clang still gets tail-call. Let me know if you want it as its own commit or squashed into this one.

[arnaud-lb]

Let's also revert this change. Or if you prefer, we could move the zend_try {} part of this function to a separate one, to avoid the conflict while also avoiding the risk non-tail recursion.

[lazerg]

Reverted. Compiled the original zend_runtime_jit() with Clang and checked the generated assembly: it emits a real tail branch (br x0 on arm64, no return address pushed) at the return site, even with the earlier sigsetjmp() call in the function. So Clang honors the tail call here without any workaround, no need for the split-function approach either.