On 2/4/20 12:15 PM, Richard Biener wrote:
On February 4, 2020 5:30:42 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote:
On Tue, 2020-02-04 at 10:34 +0100, Richard Biener wrote:
On Tue, Feb 4, 2020 at 1:44 AM Martin Sebor <mse...@gmail.com> wrote:
PR 93519 reports a false positive -Wrestrict issued for an inlined
call
to strcpy that carefully guards against self-copying. This is
caused
by the caller's arguments substituted into the call during inlining
and
before dead code elimination.
The attached patch avoids this by removing -Wrestrict from the
folder
and deferring folding perfectly overlapping (and so undefined)
calls
to strcpy (and mempcpy, but not memcpy) until much later. Calls to
perfectly overlapping calls to memcpy are still folded early.
Why do we bother to warn at all for this case? Just DWIM here.
Warnings like
this can be emitted from the analyzer?
They potentially can, but the analyzer is and will almost always
certainly be considerably slower. I would not expect it to be used
nearly as much as the core compiler.
WHether or not a particular warning makes sense in the core compiler or
analyzer would seem to me to depend on whether or not we can reasonably
issue warnings without interprocedural analysis. double-free
realistically requires interprocedural analysis to be effective. I'm
not sure Wrestrict really does.
That is, I suggest to simply remove the bogus warning code from
folding
(and _not_ fail the folding).
I haven't looked at the patch, but if we can get the warning out of the
folder that's certainly preferable. And we could investigate deferring
self-copy removal.
I think the issue is as usual, warning for code we'll later remove as dead.
Warning at folding is almost always premature.
In this instance the code is reachable (or isn't obviously unreachable).
GCC doesn't remove it, but provides benign (and reasonable) semantics
for it(*). To me, that's one aspect of quality. Letting the user know
that the code is buggy is another. I view that as at least as important
as folding the ill-effects away because it makes it possible to fix
the problem so the code works correctly even with compilers that don't
provide these benign semantics.
Martin
[*] This is in contrast to the usual (though arguably inferior) strategy
GCC employs when dealing with undefined calls to built-in functions:
call the library function even when it's certain the call will crash.
