[PR middle-end/82123] 00/06 Use EVRP range data in sprintf warnings

[Jeff Law <law@redhat.com>]

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