https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-09-23
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Blocks| |88443
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
One thing to note here is that the three Wstringop-overflow tests mentioned in
comment #0 disable -Warray-bounds. With the warning enabled the affected cases
will (should) continue to trigger the expected diagnostics on the expected
lines (and not on the in bounds accesses).
I.e., the default GCC invocation (with no special codegen or warning
suppression options) should be unaffected by the -O2 -> -O3 change, and so the
regression in the quality of these diagnostics can be viewed as only minor.
That -Warray-bounds is issued on the correct lines for these cases also
confirms the viability of the idea of moving the strlen subset
-Wstringop-overflow warnings into the -Warray-bounds pass. (As comment #6
implies, moving the whole strlen pass would likely have bigger repercussions
and is not a suitable change just to maintain warning locations).
Alternatively, since -Wstringop-overflow is documented to "warn for calls to
string manipulation functions" it might make sense to consider disabling the
-Wstringop-overflow warnings issued from the strlen pass as long as they're all
handled by -Warray-bounds. (I'm not sure they are at present: I think
out-of-bounds subobject accesses are not detected.)
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
