Reintroduce "Fix detection of unknown gcc function attributes"

[athos-ribeiro]

This PR approach has changed (see comments below and commit messages), but the original text was kept here for further discussions

Disable ifunc support on darwin to reintroduce 813d942

As described in commit 813d942, the embedded GCC macro in build/ax_gcc_func_attribute.m4 throws false negatives anytime unrelated warnings are reaised, setting have_func_attribute to no.

darwin builds do throw such warnings, meaning the ifunc support is never compiled there. Commit 813d942 introduced a fix to the macro, by only disabling the support in question when an attribute warning is raised. This revealed a possible incompatibility error in the MacOS pipeline:

```
/Users/runner/work/php-src/php-src/ext/standard/base64.c:383:95: error: unknown attribute 'ifunc' ignored [-Werror,-Wunknown-attributes]
PHPAPI zend_string *php_base64_encode(const unsigned char *str, size_t length) __attribute__((ifunc("resolve_base64_encode")));
                                                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/runner/work/php-src/php-src/ext/standard/base64.c:384:111: error: unknown attribute 'ifunc' ignored [-Werror,-Wunknown-attributes]
PHPAPI zend_string *php_base64_decode_ex(const unsigned char *str, size_t length, bool strict) __attribute__((ifunc("resolve_base64_decode")));
                                                                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
```

For this reason, 813d942 was reverted.

This PR disables ifunc support on darwin so the GCC macro can be fixed to support builds which enable additional compiler warning flags such as -Wall.

P.S.: I do not have access to a MacOS, therefore, Icould only rely on the github pipeline run to verify the MacOS counterpart of this fix. Note that the GCC macro bit of this patch has been applied in Ubuntu and Debian distributions.

[nikic]

Doesn't this indicate that this change to the m4 macro is completely broken? It only checks for -Wattributes, but here we have a failure due to -Wunknown-attributes -- this is exactly the situation this m4 macro is supposed to detect, and it doesn't :/

TBH I think we should just burn this with fire and switch everything that doesn't already do so over to __has_attribute.

[athos-ribeiro]

Hi @nikic, thanks for the review!

I extended the m4 macro to account for clang's -Wunknown-attribute as well, which should cover this specific case.

Regarding replacing the macro, should I file a separate PR for that (against master) or would you rather see it here (php 8.0) instead of the current PR? The reason I ask is that I am wondering what the consequences of removing the macro would be for extensions given it is also loaded in scripts/phpize.*

Note that once this is solved, I was planning on checking any other embedded m4 macros for upstream updates as mentioned in the previous PR.

[athos-ribeiro]

Updating this one to target PHP-8.1

[petk]

Since the __has_attribute isn't yet used in the code on these places and there is also still this concern, I think we could bypass this issue for now with something like this:

diff --git a/build/ax_gcc_func_attribute.m4 b/build/ax_gcc_func_attribute.m4
index 79f3eef82b..5ed7d8b4e5 100644
--- a/build/ax_gcc_func_attribute.m4
+++ b/build/ax_gcc_func_attribute.m4
@@ -222,7 +222,12 @@ AC_DEFUN([AX_GCC_FUNC_ATTRIBUTE], [
                  m4_warn([syntax], [Unsupported attribute $1, the test may fail])
                  int foo( void ) __attribute__(($1));
                 ]
-            )], [])
+            )], [
+              m4_case([$1],
+                [ifunc],
+                  [resolve_foo();],
+                [])
+            ])
             ],
             dnl GCC doesn't exit with an error if an unknown attribute is
             dnl provided but only outputs a warning, so accept the attribute

[petk]

For the warning of unused function resolve_foo that might be happening on some systems with clang, it is a bug fixed in clang 19:
llvm/llvm-project#87130

On GCC it works ok.

Perhaps we can simply remove the static keyword from the test or do something like this:

diff --git a/build/ax_gcc_func_attribute.m4 b/build/ax_gcc_func_attribute.m4
index 79f3eef82b..92a62698b8 100644
--- a/build/ax_gcc_func_attribute.m4
+++ b/build/ax_gcc_func_attribute.m4
@@ -151,7 +151,11 @@ AC_DEFUN([AX_GCC_FUNC_ATTRIBUTE], [
                 ],
                 [ifunc], [
                     int my_foo( void ) { return 0; }
+                    #if defined(__clang__) && (__clang_major__ < 19)
+                    int (*resolve_foo(void))(void) { return my_foo; }
+                    #else
                     static int (*resolve_foo(void))(void) { return my_foo; }
+                    #endif
                     int foo( void ) __attribute__(($1("resolve_foo")));
                 ],
                 [leaf], [