[php-src] PR #23753: Fix GH-23752: Restore GCC diagnostic state around global registers
| From: | yqtian-se | Date: | Fri, 18 Sep 2026 13:56:45 +0000 |
| Subject: | [php-src] PR #23753: Fix GH-23752: Restore GCC diagnostic state around global registers | ||
| Groups: | php.git-pulls | ||
| Request: | Send a blank email to git-pulls+get-38559@lists.php.net to get a copy of this message | ||
Pull Request: https://github.com/php/php-src/pull/23753
Author: yqtian-se
The global-register declarations need a local
-Wvolatile-register-var exception, but
the closing #pragma GCC diagnostic warning sets a new warning state instead of
restoring the build's command-line policy. GCC diagnostic pragmas override command-line
options, and warning explicitly downgrades this diagnostic even when the caller
selected -Werror.
Consequently, the current blocks violate either caller choice:
- under -Wno-volatile-register-var, PHP re-enables a warning the caller disabled;
- under -Werror=volatile-register-var, PHP downgrades the caller's requested error
to a warning, allowing compilation to continue.
The blocks are near the start of source files containing 5,733 and 1,327 lines, so this changed
state covers most of both translation units. This patch uses #pragma GCC diagnostic
push and pop around the three declarations. PHP's required declarations
remain suppressed, while the exact prior state resumes immediately afterward.
Validation on x86-64 Linux with GCC 11.4:
- configured PHP-8.4 with --disable-all --enable-opcache
--enable-opcache-jit and confirmed HAVE_GCC_GLOBAL_REGS=1;
- compiled the real Zend/zend_execute.lo and
ext/opcache/jit/zend_jit_vm_helpers.lo objects successfully;
- compiled wrappers containing each complete source file followed by a valid %r13
global-register warning oracle;
- with -Wno-volatile-register-var, both wrappers exited 0 with no diagnostics;
- with -Werror=volatile-register-var, both wrappers failed only at the post-source
oracle, confirming that the caller's error state was restored.
No PHPT is included because this is compile-time diagnostic state, not PHP runtime behavior. I found
no current endogenous later trigger in either translation unit, so this is not presented as a
current default-build failure. The reproduced failure is the loss of the build's diagnostic
policy, including the silent downgrade of an explicitly requested error.
Fixes #23752