Re: RFC: CONST_INT inconsistency fix

[Geoff Keating <geoffk at cygnus dot com>]

Jan Hubicka <jh@suse.cz> writes:

> Hi,
> Current handling of constants in instrucitons with mode lower than
> HOST_WIDE_INT is quite inconsistent.  In some cases value is curefully
> sign extended (as in simplify-rtx) to full HOST_WIDE_INT, while in others
> zero extend it (as unsigned constaints in rtl generation) and rest just
> keeps garbage in the upper part (such as plus_const_int).
> 
> This introduces number of headaches, one I run accross with my cmp->inc/dec
> patch this week.  GCC contains a tons of tests, such as
> INTVAL (const1) == INTVAL (const2) or INTVAL (const1) < 128, that are
> dangerous and their result depends on the garbage present in the upper part.
> 
> One of most inportant cases are the simplifiers for comparisons, that may
> result in incorrect code when different grabage appears on each side of
> comparison as shown in my testcase I checked in last week.  My original
> solution has been to keep track of mode comparison is done in, since it looked
> like easier sollution, but this is extremly tricky in some cases and patch is
> long (it is in the patches list from last month)
> 
> So my proposal is to change it, introduce function gen_trunc_int, accepting
> both constant and mode and truncating it before doing GEN_INT and replace
> all GEN_INT calls, that are potentially dangerous. Then we may kill the mode
> parameter to simplify_comparison, if I am not mistaken, since results
> will be always correct if I am not mistaken (the unsigned comparison done
> on sign extended values don't change).

> Comments?

You'll probably find that immed_double_const is the routine you are
looking for.  There's no gurantee that Pmode is smaller than a
HOST_WIDE_INT either.

-- 
- Geoffrey Keating <geoffk@cygnus.com>