On Wed, 2017-01-04 at 09:04 -0700, Jeff Law wrote: > On 01/04/2017 06:42 AM, Jason Merrill wrote: > > On Wed, Jan 4, 2017 at 8:13 AM, Alexandre Oliva <aol...@redhat.com> > > wrote: > > > On Jan 3, 2017, Jason Merrill <ja...@redhat.com> wrote: > > > > > > > Are there bugzillas for these false positive warnings? > > > > > > I don't think so. > > > > > > Did you mean in the sense that the patch silences them and thus > > > "fixes" > > > them, or in the sense that the underlying cause for the warnings > > > is not > > > fixed and someone might want to look into them at a later time? > > > > > > FWIW, I hadn't considered the latter (it doesn't seem too hard to > > > find > > > such warnings anyway; every time I try bootstrap-O3, which is not > > > very > > > often, I get a few of those), and the former didn't seem enough > > > of a > > > reason to have bug reports created. > > > > The latter; false positive warnings like this are bugs that should > > be fixed. > For the -O1 stuff the lower optimization level disables the > optimizers > that would identify and optimize away the infeasible path. > > For -O3 cases with unrolling, the unroller can create oob array > references with a guard. Our ability to exploit the guard isn't as > strong as it should be -- we've got BZs for this already. > > For the -O3 these are cases where the inliner exposes the infeasible > path, but we're not currently able to analyze the infeasible path. > > One could argue that any initializer we add ought to avoid a false > positive for -O2 or -O3 ought to be marked and a bug opened. But I > didn't feel it was worth pushing for that level of rigor since at > most > these are missed optimizations. But it would certainly be nice.
FWIW I've filed PR middle-end/78993 about the input.c false positive that Alex's patch addresses; I *think* it's a case where the inliner has exposed an infeasible path (but I could be wrong).
