Re: Modes on CONST_INTs

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Mon, 27 Nov 2000 14:56:02 -0800
> From: Geoff Keating <geoffk@geoffk.org>

> > Date: Mon, 27 Nov 2000 21:33:54 +0100
> > From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
> 
> > Right.  Also, having the signedness/unsignedness property
> > available would find more bugs, as Michael Meissner pointed out.
> > You can't really have a canonical representation of a number
> > unless you know how it was used.  Currently we have two
> > representations, for example both 255 and -1 for
> > all-bits-in-a-byte to track that, with inevitable bugs like the
> > ones at the URL; "QImode/U -1" might be an alternative.
> 
> No, we only have one.  All the 255 occurrences in the RTL are wrong.

I mean "we have currently" as in "we have currently because of
the current implementation of immed_double_const and trunc_int_for_mode".

I have a feeling that that's deliberately done that way to
distinguish signed from unsigned uses.  Not that that means the
code is correct, of course.  Those "unsigned" numbers appears
*from the beginning* (in 00.rtl) as such, not due to the twisty
maze in combine.c -- it is actually combine that produce the
"correct" sign-extended numbers.

brgds, H-P