This is the mail archive of the
mailing list for the GCC project.
Re: Modes on CONST_INTs
- To: geoffk at redhat dot com
- Subject: Re: Modes on CONST_INTs
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Date: Tue, 28 Nov 2000 00:14:33 +0100
- CC: hans-peter dot nilsson at axis dot com, hans-peter dot nilsson at axis dot com, bernds at redhat dot com, gcc at gcc dot gnu dot org
> Date: Mon, 27 Nov 2000 14:56:02 -0800
> From: Geoff Keating <email@example.com>
> > Date: Mon, 27 Nov 2000 21:33:54 +0100
> > From: Hans-Peter Nilsson <firstname.lastname@example.org>
> > 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.