This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gcc const int expressions and negative constants
> Date: Thu, 24 Aug 2000 22:49:53 +0100
> From: Neil Booth <NeilB@earthling.net>
> Cc: gcc-bugs@gcc.gnu.org
> I've come back to looking at this problem again. To recap, here's the
> code:-
>
> int main(void)
> {
> unsigned char sign;
> unsigned char integer[2] = {255 };
>
> sign = integer[0];
>
> printf ( "sign == 255: %d\n", sign == 255);
>
> return 0;
> }
>
> You mentioned that the RTL for the "sign == 255" comparison should be
> a QImode comparison comparing sign to -1. I've stepped through the
> RTL generation from tree exps (expand_expr -> emit_store_flag ->
> emit_cmp_and_jump_insn etc.), and nowhere is the 255 changed from a
> VOIDmode 255 to VOIDmode -1. The comparison is done in unsigned
> QImode, so this does not seem unreasonable. Any more clues <g>?
Somewhere, the expansion will take (int)255 and turn it into (unsigned
char)255, in tree form, or will take SImode 255 and turn it into
QImode 255. It is at this point that it should be changed into -1.
For CONST_INTs, their mode is deduced by context, so what will
actually happen is that something decides that SImode sign can be
changed into QImode sign in the comparison and than changes the
effective mode of the comparison and the CONST_INT. You are looking
for the first place that the (const_int 255) is used in a QImode
context. The bug is probably there.
There is no 'unsigned QImode' in RTL. There is only QImode. There
are unsigned comparisons, but not for equality, and the unsigned
comparisons still use sign-extended immediates, so
(leu:CC (reg:QI 23) (const_int -1)) is always true.
> The following 2 lines from emit_cmp_and_jump_insn_1 look like the
> place where is might be supposed to happen. As I'm not really sure
> what I'm looking for, this is quite hard.
>
> x = prepare_operand (icode, x, 0, mode, wider_mode, unsignedp);
> y = prepare_operand (icode, y, 1, mode, wider_mode, unsignedp);
I don't think that's the right place. This is code for taking a
QImode comparison and expanding it out to be a SImode comparison. You
want the other direction.
--
- Geoffrey Keating <geoffk@cygnus.com>