So I'm finally getting back to this. To recap, the issue here is the sprintf pass is querying global range information. As a result the range for the key object is not narrowed by the conditionals leading to the sprintf call and we get a false positive (pr81592 and pr82123).
The plan for the last few months was to use the embeddable range analyzer to get the narrowed range. I'd dropped in a bit of infrastructure to do that a while back, but got side tracked by spectre and meltdown before I could push it to completion. This patch completes the work. It ties the range analyzer into the dominator walk (which was trivial) and arranges to query the range analyzer rather than the global data. The patch is bigger than one might expect primarily because the points where we want to issue the queries are in free functions rather than in member functions. Rather than go through a round of refactoring to bring those free functions into the class hierarchy, I just passed around the range data. It's the same trivial change in a bunch of places to pass vr_values down. So it looks big, but is dead simple in reality. We query the data in 3 places in the fairly obvious way. My initial patch actually created a get_range_info member function within vr_values that had the same signature as the free function get_range_info in tree-ssanames.c That works, but ultimately I decided it was more confusing than using the existing get_value_range member function. So this version uses the existing get_value_range member function. The fix is broken into a half-dozen patches in my local tree. I didn't see any value in squashing them together -- so I'm posting them as a 6 series kit, even though they're pretty simple. Bootstrapped and regression tested on x86_64-linux-gnu. Verified it fixes both 81592 and 82123. Jeff
