This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] More CCP fixes [patch]
- From: Neil Booth <neil at daikokuya dot co dot uk>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Jason Merrill <jason at redhat dot com>,Diego Novillo <dnovillo at redhat dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 12 Aug 2002 23:55:12 +0100
- Subject: Re: [tree-ssa] More CCP fixes [patch]
- References: <20020812220644.GA20782@daikokuya.co.uk> <73310000.1029192267@warlock.codesourcery.com>
Mark Mitchell wrote:-
> >1) its true type (3 bit unsigned int) in the current type field
>
> That is only its true type when used as an lvalue.
It's true in C99 to the best of my knowledge. C++ could well be
different. Is that what you're referring to? If so, hmm, things
could be even more complicated.
> When used as an
> rvalue, its true type is whatever it was declared to be (int, unsigned
> int, etc. -- modulo the fact that "int" can mean "unsigned int"
> in a bitfield.)
>
> A reference to a bit-field in an rvalue context should be treated as
> implicitly containing the right sign extensions. That means that the
> tree node used to convert from (say) "unsigned int" to "signed int"
> should not be a NOP_EXPR -- you're not supposed to have generate code
> for a NOP_EXPR.
C99 says a bitfield is interpreted as a signed or unsigned type of the
specified number of bits. So this doesn't work for C, right? Or do
GCC trees expect a 3-bit value stored in them to have been
sign-extended?
Neil.