On 10/23/2017 05:14 PM, Jeff Law wrote:
Martin, I'd like your thoughts on this patch. One of the things I'm working on is changes that would allow passes that use dominator walks to trivially perform context sensitive range analysis as a part of their dominator walk. As I outlined earlier this would allow us to easily fix the false positive sprintf warning reported a week or two ago. This patch converts the sprintf warning code to perform a dominator walk rather than just walking the blocks in whatever order they appear in the basic block array. From an implementation standpoint we derive a new class sprintf_dom_walk from the dom_walker class. Like other dom walkers we walk statements from within the before_dom_children member function. Very standard stuff. I moved handle_gimple_call and various dependencies into the sprintf_dom_walker class to facilitate calling handle_gimple_call from within the before_dom_children member function. There's light fallout in various places where the call_info structure was explicitly expected to be found in the pass_sprintf_length class, but is now found in the sprintf_dom_walker class. This has been bootstrapped and regression tested on x86_64-linux-gnu. I've also layered my embedded VRP analysis on top of this work and verified that it does indeed fix the reported false positive. Thoughts?
If it lets us improve the quality of the range information I can't think of a downside. Besides the sprintf pass, a number of other areas depend on ranges, most of all the -Wstringop-overflow and truncation warnings and now -Wrestrict (once my enhancement is approved). It would be nice to be able to get the same improvements there. Does it mean that those warnings will need to be moved into a standalone pass? (I'm not opposed to it, just wondering what to expect if this is the route we want to go.) Martin
