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. Richard. >Jeff
