[Bug middle-end/98465] Bogus warning stringop-overread wuth -std=gnu++20 -O2 and std::string::insert

["msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.