On Mon, Jul 11, 2011 at 5:12 AM, Richard Guenther <rguent...@suse.de> wrote: > On Fri, 8 Jul 2011, Richard Guenther wrote: > >> On Fri, 8 Jul 2011, Michael Matz wrote: >> >> > Hi, >> > >> > On Fri, 8 Jul 2011, Richard Guenther wrote: >> > >> > > It should be indeed safe with the current handling of conversions, but >> > > better be safe. So, like the following? >> > >> > No. The point is that you can't compare the bounds that VRP computes with >> > each other when the outcome affects correctness. Think about a very >> > trivial and stupid VRP, that assigns the range [WIDEST_INT_MIN .. >> > WIDEST_UINT_MAX] to each and every SSA name without looking at types and >> > operations at all (assuming that this reflects the largest int type on the >> > target). It's useless but correct. Of course we wouldn't implement such >> > useless range discovery, but similar situations can arise when some VRP >> > algorithms give up for certain reasons, or computation of tight bounds >> > merely isn't implemented for some operations. >> > >> > Your routines need to work also in the presence of such imprecise ranges. >> > >> > Hence, the check that the intermediate conversion is useless needs to take >> > into account the input value range (that's conservatively correct), and >> > the precision and signedness of the target type (if it can represent all >> > value of the input range the conversion was useless). It must not look at >> > the suspected value range of the destination, precisely because it is >> > conservative only. >> >> Ok, indeed conservative is different for what VRP does and for what >> a transformation must assess. So the following patch makes >> a conservative attempt at checking the transformation (which of >> course non-surprisingly matches what the VRP part does). >> >> So, more like the following? > > The following actually works. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Can you double-check it? > > Thanks, > Richard. > > 2011-07-11 Richard Guenther <rguent...@suse.de> > > * tree-vrp.c (simplify_conversion_using_ranges): Manually > translate the source value-range through the conversion chain. >
This may have caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066 -- H.J.
