This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Help with bit-field semantics in C and C++
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 24 Aug 2004 10:32:39 -0600 (MDT)
- Subject: Re: Help with bit-field semantics in C and C++
On Mon, 23 Aug 2004, Mark Mitchell wrote:
> That conversion is unspecified in C++, as others have said.
>
> Now, the next question is what behavior we should prefer. I think that
> we should avoid generating any code for such a conversion, so that means
> that we should avoid, for example, generating mask instructions. As
> Joseph points out, it's not crystal clear whether the result of the
> conversion must result in a valid value of the underlying enumeration
> type -- but all compilers of which I am aware will just store "0x10" in
> the memory for "x" without doing any truncation, so I think that's what
> we should do too.
>
> In other words, treat this like a conversion to the underlying
> integer type for the enumeration.
I'm happy with the explanations so far. The next question is, if
the middle-end is supposed to treat loads, stores and comparisons
of these types identically to the underlying integer type for the
enumeration, is there a benefit for setting TYPE_PRECISION lower
than GET_MODE_BITSIZE for C++'s enumerated types?
Even if there are book keeping advantages (correctness?) for the
C++ front-end to treat these as bit-field types, there are clearly
simplifications to the middle-end to deal with them as regular
integral types, than introduce a new class of integeral types that
are neither zero nor sign extended.
I'm happy to add all of the necessary middle-end checks to test for
TYPE_PARADOXICAL_P, but before doing that I'd like to confirm that
the C++ front-end end really needs them. After all these regressions
are from gcc 3.3 and earlier where we really did represent these
values as the underlying integer type.
Isn't this behaviour allowed by the "unspecified" freedoms of the
C++ standard, or is there some other user observable difference from
these changes? Debugging output perhaps? Were there any c++ PRs
that were fixed by these changes that I need to be carefull to avoid
breaking with my middle-end changes?
As always, please forgive my ignorance.
Roger
--