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? I wonder if there's a way for me to test this from the GCC side. 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>. Dave _______________________________________________ linaro-toolchain mailing list -- [email protected] To unsubscribe send an email to [email protected]
