------- Comment #3 from vsoni at tilera dot com 2010-03-17 19:33 ------- (In reply to comment #2) > > I read that t.f promotes to int. And that is exactly what the C++ frontend > does:
That's plausible, but the standard, especially it's intent, is unclear I think. I see three plausible interpretations: A) int can represent all values of a long:16 bit-field, AND a long:16 bit-field is not larger than int (if "larger" is interpreted with respect to the number of bits in the bit-field representation, i.e. 16 bits). So it is converted to int. B) int can represent all values of a long:16 bit-field, BUT a long:16 bit-field is larger than int and unsigned int (if "larger" is interpreted with respect to the size of the declared type of the bit-field, i.e. long). So two clauses of [3] apply, and the question is order of precedence: B1) The clause concerning int-representable values takes precedence, so it is converted to int. B2) The clause concerning the size of the bit-field takes precedence, so no integer promotions apply, and it remains long. I agree that [A] seems to be the "simplest" interpretation in some sense, and perhaps it's the correct one, but I can't reconcile this with the following: It seems to me the programmer's intent when declaring a bit-field of type long:N, is to treat the value as type long, independent of N. It also seems to me that's the intent of the standard when it states that the number of bits in a bit-field is not part of its type; perhaps the intent is something else? FWIW, I searched but did not find a discussion of rationale, or a conclusive example, in the supplementary notes of the C++ Standards Committee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43393