Re: [patch] expr.c: Fix PR middle-end/18008.

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 18 Oct 2004, Jason Merrill wrote:
> >> After the tree optimizers run, I get
> >>
> >>   b->b = (<unnamed type>) (unsigned char) v;
> >>
> >> where <unnamed type> is a 2-bit integer type.  The problem is that we
> >> get ANDs from two places.  The first one is generated by the cast to
> >> (<unnamed type>).  The second one is from the assignment, more
> >> specifically store_bit_field.
> >>
> >> The patch fixes the problem by stripping a narrowing conversion.
>
> It seems to me that the right fix is to avoid generating an AND in
> store_bit_field if the value assigned is already appropriately narrow.

Unfortunately, the RTL expanders currently assume that when bit-field
types whose precisions are narrower than their modes are stored in
pseudos, that all the high bits are undefined.  This is identical to the
issue with C++ enumerations, where the middle-end can't rely on a variable
being one of the enumeral values or even in the range of enumeral values.
i.e. at the tree-level, all bitfields are paradoxical, and the GCC type
system has no way of recording that such values are (or should be) zero
or sign-extended.

This is a bit of a pain for tree-ssa, as converting

	x = y;

into the semantically equivalent

	t = y;
	x = t;

introduces an additional AND operation! Doh!

And obviously,

	t1 = y;
	t2 = t1;
	x = t2;

introduces two additional AND operations! Doh! Doh!

At the point we expand "x = t", we can't be sure that "t" is correctly
sign-extended/zero-extended, or has been assigned directly "t = -1".

Roger
--