Ping 3:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
I submitted this as a fix for a fair number of false positives
reported by Fedora package maintainers. Last week Jakub committed
r11-7146, which is an alternate workaround for the same problem,
but one isolated to libstdc++. That might make this patch less
pressing but not less relevant since it also fixes pr98512 (a bug
impacting Glibc) and adds the infrastructure for resolving pr98871
and other bugs about the #pragma diagnostic's inability to suppress
warnings in inlined code.
Jeff (or anyone else who cares about this) if you consider this
patch too intrusive at this point let me know and I'll stop pinging
it and resubmit it for GCC 12.
On 2/6/21 10:12 AM, Martin Sebor wrote:
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
On 1/29/21 7:56 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html
On 1/21/21 4:46 PM, Martin Sebor wrote:
The initial patch I posted is missing initialization for a couple
of locals. I'd noticed it in testing but forgot to add the fix to
the patch before posting it. I have corrected that in the updated
revision and also added the test case from pr98512, and retested
the whole thing on x86_64-linux.
On 1/19/21 11:58 AM, Martin Sebor wrote:
std::string tends to trigger a class of false positive out of bounds
access warnings for code GCC cannot prove is unreachable because of
missing aliasing constrains, and that ends up expanded inline into
user code. Simply inserting the contents of a constant char array
does that. In GCC 10 these false positives are suppressed due to
-Wno-system-headers, but in GCC 11, to help detect calls rendered
invalid by user code passing in either incorrect or insufficiently
constrained arguments, -Wno-system-header no longer has this effect
on invalid access warnings.
To solve the problem without at least partially reverting the change
and going back to the GCC 10 way of things for the affected subset
of calls (just memcpy and memmove), the attached patch enhances
the #pragma GCC diagnostic machinery to consider not just a single
location for inlined code but all locations at which an expression
and its callers are inlined all the way up the stack. This gives
each author of a function involved in inlining the ability to
control a warning issued for the code, not just the user into whose
code all the calls end up inlined. To resolve PR 98465, it lets us
suppress the false positives selectively in std::string rather
than across the board in GCC.
The solution is to provide a new pair of overloads for warning
functions that, instead of taking a single location argument, take
a tree node from which the location(s) are determined. The tree
argument is indirect because the diagnostic machinery doesn't (and
cannot without more intrusive changes) at the moment depend on
the various tree definitions. A nice feature of these overloads
is that they do away with the need for the %K directive (and in
the future also %G, with another enhancement to accept a gimple*
argument).
This patch depends on the fix for PR 98664 (already approved but
not yet checked in). I've tested it on x86_64-linux.
To avoid fallout I tried to keep the changes to a minimum, and
so the design isn't as robust as I'd like it ultimately to be.
I plan to enhance it in stage 1.
Martin
