Merge branch 'PHP-8.2' into PHP-8.3

* PHP-8.2:
Do not remove -O0 in the middle of a flag
Fix removal of optimization cflags in debug builds (#9647)

Do not remove -O0 in the middle of a flag

Fixes GH-15826
Closes GH-15828

Co-authored-by: Peter Kokot <petk@php.net>

Merge branch 'PHP-8.2' into PHP-8.3

* PHP-8.2:
Fix incompatible function pointer types

Fix incompatible function pointer types

Closes #14549

Merge branch 'PHP-8.2' into PHP-8.3

* PHP-8.2:
Fix incompatible pointer type warnings

Fix incompatible pointer type warnings

This fixes the incompatible pointer type warnings when checking for
reentrant functions declaractions (-Wincompatible-pointer-types) in
config.

Fix incompatible pointer type warnings

This fixes the incompatible pointer type warnings when checking for
reentrant functions declaractions (-Wincompatible-pointer-types) in
config.log. These were not declared on some obsolete systems if
_REENTRANT was not defined. The check is for now left in the code base
but can be transitioned to newer code without checking for missing
declarations or using these otherwise in the future.

Closes GH-14315.

show more ...

Merge remote-tracking branch 'origin/PHP-8.2' into PHP-8.3

Fix check for newer versions of ICU (#14186)

* Fix check for newer versions of ICU

The previous test would always trigger, even if the version of ICU
installed didn't require C+

Fix check for newer versions of ICU (#14186)

* Fix check for newer versions of ICU

The previous test would always trigger, even if the version of ICU
installed didn't require C++17. This was because it incorrectly used
the `test` program, which broke the build on systems without a C++17
compiler.

Tested with macOS 14 and i 7.2.

* Fix broken ICU version check for definition

Same as the previous fix for C++17.

---------

Co-authored-by: Peter Kokot <peterkokot@gmail.com>

show more ...

Merge branch 'PHP-8.2' into PHP-8.3

Fix GH-13727: macro generating invalid call test prototypes fixes.

autoconf/libtool generating code to test features missed `void` for
C calls prototypes w/o arguments.
Note that spe

Fix GH-13727: macro generating invalid call test prototypes fixes.

autoconf/libtool generating code to test features missed `void` for
C calls prototypes w/o arguments.
Note that specific changes related to libtool have to be upstreamed.

Co-authored-by: Peter Kokot <petk@php.net>

close GH-13732

show more ...

Merge branch 'PHP-8.2' into PHP-8.3

* PHP-8.2:
Set libtool tag per command instead of global one

Set libtool tag per command instead of global one

Global --tag=CC defined in configure.ac is not correct in all cases. For example
linking objects that were compiled from C++ sources nee

Set libtool tag per command instead of global one

Global --tag=CC defined in configure.ac is not correct in all cases. For example
linking objects that were compiled from C++ sources needs to be done with C++
compiler, however for link mode libtool will prefer compiler indicated with
--tag.

Fixes GH-12349

show more ...

Fix GH-12273 - configure __builtin_cpu_init() check

__builtin_cpu_init() is documented as having a void return type. It happens to
return int on gcc, but is void on clang.

Clos

Fix GH-12273 - configure __builtin_cpu_init() check

__builtin_cpu_init() is documented as having a void return type. It happens to
return int on gcc, but is void on clang.

Close GH-122274

show more ...

Merge branch 'PHP-8.1' into PHP-8.2

Fix GH-12273 - configure __builtin_cpu_init() check

__builtin_cpu_init() is documented as having a void return type. It happens to
return int on gcc, but is void on clang.

Clos

Fix GH-12273 - configure __builtin_cpu_init() check

__builtin_cpu_init() is documented as having a void return type. It happens to
return int on gcc, but is void on clang.

Close GH-122274

show more ...

Remove CPP when invoking dtrace utility

We are experiencing an issue when building PHP with DTrace enabled with
SystemTap (see GH-11847).† The issue is caused by inappropriate use C

Remove CPP when invoking dtrace utility

We are experiencing an issue when building PHP with DTrace enabled with
SystemTap (see GH-11847).† The issue is caused by inappropriate use C
preprocessor detected by GNU Autoconf in our “configure” script. C
preprocessor configuration found by AC_PROG_CPP macro is portable only
to run on files with “.c” extension.‡ However, statically-defined tracing
is described by D programs with “.d” extension which causes the issue.
We experience this even on typical Linux distribution with GNU Compiler
Collection (GCC) unless we override the defaults detected by our
“configure” script.

Many major Linux distributions use SystemTap to provide “dtrace”
utility. It relies on both external C preprocessor and external C
compiler. C preprocessor can be customized via CPP environment variable.
Similarly, C compiler can be customized via CC environment variable. It
also allows customization of C compiler flags via CFLAGS environment
variable. We have recently aligned both CPP and CC environment variable
with C preprocessor and C compiler we use to build regular C source code
as provided by our “configure” script (see GH-11643).* We wanted to
allow cross-compilation on Linux for which this was the only blocker. C
compiler flags from CFLAGS_CLEAN macro have already been in place since
versions 5.4.20 and 5.5.4 from 2013-09-18.

We had modified all “dtrace” invocations in the same way to make it look
consistent. However, only the C compiler (CC environment variable) is
necessary to for cross-compilation. There have never been any reported
issue with the C preprocessor. We acknowledge it would be great to allow
C preprocessor customization as well. However, the implementation would
require a lot of effort to do correctly given the limitations of
AC_PROG_CPP macro from GNU Autoconf. This would be further complicated
by the fact that all DTrace implementations, not just SystemTap, allow C
preprocessor customization but Oracle DTrace, Open DTrace, and their
forks do it differently. Nevertheless, they all default to “cpp” utility
and they all have or had been working fine. Therefore, we believe simply
removing CPP stabilizes “dtrace” invocation on Linux systems with
SystemTap and aligns it with other system configurations on other
platforms, until someone comes with complete solution with custom “m4”
and “make” macros, while our build system on Linux with SystemTap
supports cross-compilation.

Fixes GH-11847
Closes GH-12083

† https://github.com/php/php-src/issues/11847
‡ https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#index-AC_005fPROG_005fCPP-1
* https://github.com/php/php-src/issues/11643

show more ...

Improve DTrace probe generation /w non-default compiler

With DTrace support enabled during ./configure, our custom Autoconf
macro PHP_INIT_DTRACE creates make rules to generate header an

Improve DTrace probe generation /w non-default compiler

With DTrace support enabled during ./configure, our custom Autoconf
macro PHP_INIT_DTRACE creates make rules to generate header and object
files using dtrace utility. SystemTap† implementation of dtrace relies
on other utilities to provide header preprocessing and final object file
compilation. These utilities are configured by common environment
variables with common defaults:‡

* preprocessor from CPP defaults to “cpp”
* compiler from CC defaults to “gcc”
* compiler arguments can be expanded with CFLAGS

This has been in SystemTap since version 1.5 released on 2011-05-23. We
have been setting CFLAGS for dtrace since 717b367 released in versions
5.4.20 and 5.5.4 on 2013-09-18. This change fixed build against
SystemTap. It fixes majority of cases since practically all free Linux
distributions use SystemTap for DTrace-like dynamic tracing and
practically all of them use GCC or compatible compiler suite. However,
this becomes an issue when cross-compiling using GCC because utility
names contain target triplets. Autoconf already handles
cross-compilation well —setting correct CC and CPP make macros
(variables).

Therefore, we simply set CC and CPP environment variables using
respective macros when executing dtrace. Although SystemTap dtrace does
not always use CC nor CPP, we set it every time. SystemTap documentation
does not talk about this at all¶, so it is safer to always set it. We
also follow how we set CFLAGS every time in the past.

Original (or ported) DTrace mainly used on Oracle Linux, Solaris and
macOS ignores these and does not support cross compilation.§

† Well-known dynamic tracing infrastructure for Linux compatible with
statically-defined tracing from DTrace.
‡ https://sourceware.org/git/?p=systemtap.git;a=blob;f=dtrace.in;h=73a6f22e2de072773c692e3fea05c4b8cf814e43;hb=ebb424eee5599fcc131901c0d82d0bfc0d2f57ab
¶ https://sourceware.org/systemtap/man/dtrace.1.html
§ https://docs.oracle.com/cd/E88353_01/html/E72487/dtrace-8.html

Closes GH-11643

show more ...

Fix GH-9483: Autoconf warnings for newer Autoconf versions

Co-authored-by: Levi Morrison <morrison.levi@gmail.com>

Merge branch 'PHP-8.2'

* PHP-8.2:
Fix GH-11522: PHP version check fails with '-' separator

Merge branch 'PHP-8.1' into PHP-8.2

* PHP-8.1:
Fix GH-11522: PHP version check fails with '-' separator

Fix GH-11522: PHP version check fails with '-' separator

Remove php version suffix from '-' separator.

Closes GH-11524.

*/*.m4: update main() signatures.

The next generation of C compilers is going to enforce the C standard
more strictly:

https://wiki.gentoo.org/wiki/Modern_C_porting

O

*/*.m4: update main() signatures.

The next generation of C compilers is going to enforce the C standard
more strictly:

https://wiki.gentoo.org/wiki/Modern_C_porting

One warning that will soon become an error is -Wstrict-prototypes.
This is relatively easy to catch in most code (it will fail to
compile), but inside of autoconf tests it can go unnoticed because
many feature-test compilations fail by design. For example,

$ export CFLAGS="$CFLAGS -Werror=strict-prototypes"
$ ./configure
...
checking if iconv supports errno... no
configure: error: iconv does not support errno

(this is on a system where iconv *does* support errno). If errno
support were optional, that test would have "silently" disabled
it. The underlying issue here, from config.log, is

conftest.c:211:5: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
211 | int main() {

This commit goes through all of our autoconf tests, replacing main()
with main(void). Up to equivalent types and variable renamings, that's
one of the two valid signatures, and satisfies the compiler (gcc-12 in
this case).

Fixes GH-10751

show more ...

base64: add avx512 and vbmi version. (#6361)

1. Implementation based on https://github.com/WojciechMula/base64simd
2. Only runtime path is added to reduce the complexity of SIMD variants

base64: add avx512 and vbmi version. (#6361)

1. Implementation based on https://github.com/WojciechMula/base64simd
2. Only runtime path is added to reduce the complexity of SIMD variants.
3. Expand test case to cover SIMD implementation.

Signed-off-by: Frank Du <frank.du@intel.com>

show more ...

Bump minimum re2c version requirement to 1.0.3

The release VMs already enforced this, but PHP's configure script did
not.

re2c 0.13.5, which timelib's date/time parser requires

Bump minimum re2c version requirement to 1.0.3

The release VMs already enforced this, but PHP's configure script did
not.

re2c 0.13.5, which timelib's date/time parser requires is no longer
compatible with the current version of Zend/zend_language_scanner.l, as
it starts spinning in a loop.

show more ...

Add AVX2-accelerated UTF-16 decoding/encoding routines

As with other SIMD-accelerated functions in php-src, the new UTF-16
encoding and decoding routines can be compiled either with AVX2

Add AVX2-accelerated UTF-16 decoding/encoding routines

As with other SIMD-accelerated functions in php-src, the new UTF-16
encoding and decoding routines can be compiled either with AVX2
acceleration "always on", "always off", or else with runtime detection
of AVX2 support.

With the new UTF-16 decoder/encoder, conversion of extremely short
strings (as in several bytes) has the same performance as before,
and conversion of medium-length (~100 character) strings is about 65%
faster, but conversion of long (~10,000 character) strings is around
6 times faster.

Many other mbstring functions will also be faster now when handling
UTF-16; for example, mb_strlen is almost 3 times faster on medium
strings, and almost 9 times faster on long strings. (Why does mb_strlen
benefit more from AVX2 acceleration than mb_convert_encoding? It's
because mb_strlen only needs to decode, but not re-encode, the input
string, and the UTF-16 decoder benefits much more from SIMD
acceleration than the UTF-16 encoder.)

show more ...