David Malcolm via linaro-toolchain <[email protected]> writes:
> On Fri, 2025-11-21 at 20:15 +0000, Joseph Myers wrote: >> On Fri, 21 Nov 2025, [email protected] 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 <[email protected]> >> > | 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/2276/artifact/artifacts/00-sumfiles/gcc.log.1.xz > 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_installed_location > 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>. -- Thiago _______________________________________________ linaro-toolchain mailing list -- [email protected] To unsubscribe send an email to [email protected]
