On Wed, Oct 20, 2021 at 10:01 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 10/20/2021 9:15 AM, Aldy Hernandez wrote: > > On Wed, Oct 20, 2021 at 4:35 PM Martin Sebor <mse...@gmail.com> wrote: > > > >> I appreciate the heads up. I'm happy that the threader has > >> improved. I'm obviously not pleased that it has led to regressions > >> in warnings but I understand that in some cases they might be due > >> to limitations in the warning code. I think the test case you have > >> xfailed might be one such example. The uninitialized warnings are > >> exquisitely sensitive to these types of changes. If/when this patch > >> is applied please reopen PR 89230 and reference this commit. > >> > >> Having said that, to maintain the quality of diagnostics, > >> the work that goes into these nice optimizer improvements needs > >> to be balanced by an effort to either update the warning code > >> to cope with the IL changes, or the optimizers need to take care > >> to avoid exposing undefined code that the warnings are designed > >> to detect. I'm concerned not just that the quality of GCC 12 > >> diagnostics has been eroding, but also that it seems to be not > >> just acceptable but expected. > > You make a very good point. It is certainly not my intention to make > > life difficult for the warning maintainers, but I'm afraid I don't > > have sufficient knowledge in the area to improve them. > > > > There may be some low hanging fruit though. At least in the warnings > > that use the ranger, there's no reason to run these passes so late in > > the pipeline. You could run the warning code as early as you want, > > insofar as SSA is available and the CFG has been built. Heck, you may > > even be able to run at -O0, though we may need some sort of value > > numbering. I believe Richi even suggested this a while back. > Running them later in the pipeline is to take advantage of the > optimizers removing dead and unreachable code as much as possible. In > fact, that's critical to -Wuninitialized. Optimizing away unreachable > paths to avoid Wuninitialized false positives has been the major driver > of jump threading improvements for the last 15 years.
Ughh, that's unfortunate. We're gonna have to come up with improvements to the Wuninitialized code, or a different paradigm altogether. I'm afraid this will only get worse. It is a bit ironic that jump threading helps reduce Wuninitialized false positives, but yet too much of it causes even more false positives. Aldy
