This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] More CCP fixes [patch]

--On Monday, August 12, 2002 11:55:12 PM +0100 Neil Booth <> wrote:

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.
No, I think it's the same -- but I don't have a C99 standard handy.

The C++ standard has no notion of a "3-bit integer type".  It has
bool, char, short, int, long, and wchar_t, with signed/unsigned
variants as appropriate.

The C++ standard says:

 A member-declarator of the form identifieropt : constant-expression
 specifies a bit-field; its length is set off from the  bit-field  name
 by  a  colon.   The bit-field attribute is not part of the type of the
 class member.

Note the last sentence.

I'm not sure that the C++ standard says what happens when you assign
"12" to a 2-bit bitfield.  (Do you get truncation, or undefined
behavior?)  It does provide certain guarantees about assigning booleans
and enumerals to bitfields and then reading their values back.

The front end shouldn't be dealing in types that don't exist in the
language.  If, at some point, some code-generation thingy needs to
mess about with things -- including creating new types -- well,
that's its business and I've no objection.

My opinion is that in the front end we shouldn't be doing anything
special about bitfields.  They should have the type they are declared
to have, and they should be used in the tree just like any other
FIELD_DECL; except, of course, that their cannot be an ADDRESS_EXPR
around them.  Values assigned to bitfields should have the same type
as the bitfield.

Mark Mitchell      
CodeSourcery, LLC  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]