https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126172
--- Comment #2 from Bruno Haible <bruno at clisp dot org> --- (In reply to Drea Pinski from comment #1) > -Wsystem-headers > > > # 31 "bug.c" 3 > rpl_free > # 31 "bug.c" > > The 3 here means it came from a system header. > It is a bit odd that you have a free defined in a system header ... Yes, the macro definition "#define free rpl_free" comes from a system header. Namely, from a Gnulib-generated stdlib.h file. These Gnulib-generated .h files use "#pragma GCC system_header" because they make use of '#include_next', and these uses of '#include_next' would otherwise produce warnings with 'gcc -pedantic'. The test case that I provided is a reduced one, of course. The realistic use of -Wmismatched-dealloc is in https://lists.gnu.org/archive/html/bug-gnulib/2026-07/msg00012.html. > So the warning is going to be supressed. > > https://gcc.gnu.org/onlinedocs/gcc-16.1.0/cpp/Preprocessor-Output.html This documentation says "certain warnings should be suppressed". IMO it's reasonable that a warning about #include_next gets suppressed when it occurs in a system header, because #include_next operates on the preprocessing level. But * -Wmismatched-dealloc is a warning about semantics, * only a small part of the 'rpl_free (s)' expression comes from a system header; the argument list '(s)' does not come from a system header. Therefore the -Wmismatched-dealloc warning option should ignore the origin of the rpl_free token.
