https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> --- (In reply to Romain Geissler from comment #2) > There seems to be a strange interaction between -Wsystem-headers and -g in > gcc 11 which I don't understand. Thanks for the -g hint; with it I can see it on my end as well. The difference seems to be in how the inlining information is encoded with -g vs without. With -g, the algorithm that looks for the location into which the call to s.insert() has been inlined manages to uncover it. Without -g, the algorithm fails and falls back on the traditional approach that only considers macro expansion but not inlining. So without -g, the warning is not issued because of a bug or limitation in the new algorithm. (The algorithm was introduced in r11-6028 to enable -Wfree-nonheap-object and other similar middle-end warnings for invalid uses of C++ standard library functions. The goal is to avoid issuing warnings for deliberate abuses by system headers, but we want to issue those for incidental misuses of system functions by user code.) (In reply to Romain Geissler from comment #3) > Why does having a function f2 affects warnings in function f1 ? Because s.insert() is a trivial wrapper around replace(), calls to it end up expanded inline into those to s._M_replace(). When there's just one caller of s1.insert(), the latter is inlined into it as well. But with two or more callers, because _M_replace() is big, the inliner decides it's better not to expand it inline. That in turn prevents constant propagation from substituting the constant array's address into the code, which then defeats the warning. The inlining limit is controlled by -finline-limit=n so suitably increasing it will trigger the warning.
