* [JIT] Print out more meaningful warning message
When the setting value is out of range for jit_hot_loop, jit_hot_func,
jit_hot_return, and jit_hot_side_exit, current PHP only prints out
warning message like:
Warning: Invalid "opcache.jit_hot_loop" setting.
Should be between 0 and 256 in Unknown on line 0
With this small patch, PHP can print out more meaningful information,
and tell user default value will be used and correct value range, like
Warning: Invalid "opcache.jit_hot_loop" setting; using default value instead.
Should be between 0 and 255 in Unknown on line 0
This patch has been verified on my local machine.
Signed-off-by: Su, Tao <tao.su@intel.com>
Co-authored-by: Michael Voříšek <mvorisek@mvorisek.cz>
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
Closes GH-7955.
When bug 77574[1] has been fixed, the fix only catered to variables
retrieved via `getenv()` with a `$varname` passed, but neither to
`getenv()` without arguments nor to the general import of environment
variables into `$_ENV` and `$_SERVER`. We catch up on this by using
`GetEnvironmentStringsW()` in `_php_import_environment_variables()` and
converting the encoding to whatever had been chosen by the user.
[1] <https://bugs.php.net/bug.php?id=75574>
Closes GH-7928.
We explicitly check for an exception after the logging attempt, and
bail out in that case.
Co-authored-by: Tim Düsterhus <timwolla@googlemail.com>
Closes GH-7878.
The output of token_get_all is unaffected, so projects such as the userland
nikic/php-parser are unaffected.
Extensions such as nikic/php-ast which expose the internal php ast would see
literals be flattened, though.
This makes php significantly faster at parsing code such as
`$x = eval('return ' . var_export(str_repeat("\0", 100), true) . ';');`
and avoids the stack overflow from recursing 100000 times in
zend_eval_const_expr to process `'' . "\0" . '' . "\0" . ...`
Closes GH-7946
* Don't create binary op if unnecessary
* Update Zend/zend_ast.c
Co-authored-by: Nikita Popov <nikita.ppv@googlemail.com>
* PHP-8.1:
fix GH-7899 Regression in unpack for negative int value
Fix ext/zend_test/tests/observer_bug81430_2.phpt failure
JIT: Fix incorrect flag check
Casting from pointer to array is special, so we must not fall back to
the general FFI casting. There is a particular issue regarding the
size comparison, namely that the pointer size is always 8 for 64bit
architectures, but the size of an array is determined by its
declaration, so as is casting a pointer to an array with more than 8
elements would fail, but casting to an array with less than 9 elements
succeeds, but the internal pointer would point to some arbitrary
memory.
We fix this by properly supporting the cast. An alternative would be
to deny this kind of cast generally, since it is not necessarily safe.
However, FFI isn't necessarily safe anyway.
We also check pointer/array type compatibility when casting.
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
Closes GH-7876.
While JMPZNZ can avoid execution of a separate JMP opcode in some
cases, it also prevents smart branch optimization, so creating
JMPZNZ may actually have a negative effect. It also adds additional
complexity for optimizations.
Drop JMPZNZ in favor of JMPZ+JMP or JMPNZ+JMP.
Closes GH-7857.
David CARLIER