On 12/07/2016 02:24 PM, Jakub Jelinek wrote:
On Wed, Dec 07, 2016 at 02:18:15PM -0700, Jeff Law wrote:
On 12/05/2016 02:14 PM, Jakub Jelinek wrote:
Hi!
As shown on the testcase, with K&R definitions and fn prototypes with
promoted types, we can end up computing caller's value ranges in wider
type than the parameter actually has in the function.
The problem with that is that wide_int_storage::from can actually wrap
around, so either as in the testcase we end up with invalid range (minimum
larger than maximum), or just with a range that doesn't cover all the values
the parameter can have.
The patch punts if the range bounds cast to type aren't equal to the
original values. Similarly (just theoretical), for pointers it only
optimizes if the caller's precision as at most as wide as the pointer,
if it would be wider, even ~[0, 0] range could actually be a NULL pointer
(some multiple of ~(uintptr_t)0 + (uintmax_t) 1).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-12-05 Jakub Jelinek <ja...@redhat.com>
PR tree-optimization/78681
* ipa-prop.c (ipcp_update_vr): Punt if vr[i].min precision is bigger
then type's precision and vr[i].min or vr[i].max in type would wrap.
* gcc.c-torture/compile/pr78681.c: New test.
OK. If the work on the thread for 78365 produces fruit we can always go
back and make this less pessimistic.
Richard actually prefers the other patch (still pending review).
Then let's wait for Richard to chime in on the other patch. I'm not
real familiar with this code, but I could easy convince myself your
change could do no harm. I'm much less comfortable evaluating the other
approach.
jeff
