------- Comment #8 from law at redhat dot com 2006-01-26 17:14 ------- Subject: Re: [4.2 Regression] ACATS ICE cxac0004 in set_value_range, at tree-vrp.c:161 on x86-linux
On Tue, 2006-01-24 at 15:12 -0700, Jeffrey A Law wrote: > That "fixes" cxac004, but causes c99004a to fail! As Laurent noted, c99004a has been failing without rhyme or reason and the failure is not an indication of a regression due to my patch. So I'm going to go forward with my patch. The basic problem is we query SCEV to get ranges in some cases and we query it on a different type than we ultimately care about. And I've been unable to convince myself that even if we passed it the right type that SCEV would do the right thing. This patch makes VRP check the result of querying SCEV against the type we actually care about. When SCEV's result is inconsistent with the type we car about, we simply ignore SCEV's result. This patch also refines my recent change in one case. Specifically if we are intersecting a VR_RANGE and VR_ANTI_RANGE where the VR_ANTI_RANGE is completely contained within the VR_RANGE, we have the option of using either the VR_RANGE or VR_ANTI_RANGE as the result. We were selecting the VR_ANTI_RANGE, but in practice the VR_RANGE is likely going to be more precise. So I've changed the code to give us the VR_RANGE instead. About the only time the VR_ANTI_RANGE might be more useful would be if it was something like -[0, 0] and referred to a pointer type. Note that I'll be looking more closely at the VRP null-pointer check elimination code shortly so if the need arises I may add that final bit of refinement. Anyway, bootstrapped and regression tested on i686-pc-linux-gnu (ada included). Jeff ------- Comment #9 from law at redhat dot com 2006-01-26 17:14 ------- Created an attachment (id=10735) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10735&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25900