David Malcolm via linaro-toolchain linaro-toolchain@lists.linaro.org writes:
On Fri, 2025-11-21 at 20:15 +0000, Joseph Myers wrote:
On Fri, 21 Nov 2025, ci_notify@linaro.org wrote:
Dear contributor,
Our automatic CI has detected problems related to your patch(es). Please find some details below.
In master-aarch64, after: | commit glibc-2.42.9000-537-gcd748a63ab1 | Author: Joseph Myers josmyers@redhat.com | Date: Thu Nov 20 19:30:27 2025 +0000 | | Implement C23 const-preserving standard library macros | | C23 makes various standard library functions, that return a pointer | into an input array, into macros that return a pointer to const when | the relevant argument passed to the macro is a pointer to const. (The | ... 35 lines of the commit log omitted.
Produces 5 regressions: | | regressions.sum: | Running gcc:gcc.dg/analyzer/analyzer.exp ... | FAIL: gcc.dg/analyzer/strchr-1.c (test for warnings, line 32) | FAIL: gcc.dg/analyzer/strchr-1.c (test for warnings, line 39) | FAIL: gcc.dg/analyzer/strchr-1.c (test for excess errors) | FAIL: gcc.dg/analyzer/strchr-1.c event at line 33 (test for warnings, line 32)
I'm not sure why this test is using the strchr declaration from <string.h> as well as __builtin_strchr, but depending on the goals of doing so, the options to fix this are either making the test const-correct so it works with the C23 macro, or suppressing macro expansion.
Do you have a URL for the failure?
You can find the log for the failure above here:
https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-build/22...
I wonder if there's a way for me to test this from the GCC side.
I haven't tried yet, but I believe you can reproduce by building the gcc testcase against glibc from trunk as described here:
https://sourceware.org/glibc/wiki/Testing/Builds#Compile_against_glibc_in_an...
The intent of the test is to verify that the analyzer "knows" about the behavior of strchr, so the best fix here probably is to simply use __builtin_strchr throughout, and drop the include of <string.h>.