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. Another thing you could do is rewrite your passes to use actual ranges, not the pair of ranges that the sprintf code uses (for example). We've put a lot of work into making infinite ranges work. There's no reason to keep using value_ranges, anti ranges, and all that. I've mentioned this many times in the past 2+ years. I even tried my hand at doing the conversion myself, but I'm afraid I don't understand the intricacies of the code very well. I've done all I can in this area, including porting all the evrp consumers to the ranger, and recently providing patches for converting the strlen / sprintf passes. I'm sorry to rant here, but I've made lots of suggestions in the past couple years, and they go unheeded. I eventually get frustrated and end up doing a half assed conversion of what I can, myself. Furthermore, I've mentioned in the past that the sprintf warnings (and possibly the overflow ones) depend on precise internal ranges that evrp or the ranger are calculating. The fact that they're hard to read, make it less likely that others (well me, anyhow) will chime in to help. It's hard enough to understand the warnings, let alone the code generating them. Andrew has also suggested some things in this area. ISTR there was some overloading of the base functions you could do to represent pointer offsets, though I can't remember the details. Barring the above, at the top of our list for next year is full support for pointers and floats. The pointer bits should help, but you must convert your passes for that to happen. Pairs of integers are far too fragile. And finally, if none of that improves things sufficiently, Andrew and I have batted around providing an infrastructure for predication that can replace the uninit stuff which is showing its age, but alas that's a ways away. Aldy
