bitfield types

[Mike Stump]

On Nov 14, 2017, at 3:21 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Tue, 14 Nov 2017, Mike Stump wrote:
>> The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me.  The 
>> type of the expression x.b << 8 has size 8, a size 8 integral type is a 
>> 64-bit type.  If the result is a 64-bit type, then it's argument (x.b) 
>> was a 64-bit type.  In C++, we observed what they meant in the C 
> 
> A 64-bit type *with padding bits, not necessarily 64 value bits*.
> 
> See what I said in <https://gcc.gnu.org/ml/gcc/2017-10/msg00192.html>.

Ah, thanks.

> I don't know what if anything in C++ explicitly resolves the C90 DR#120
> issue and defines the results of storing not-exactly-representable values
> in a bit-field.

The text that you'd most be interest in, from C++98:d

2 If the destination type is unsigned, the resulting value is the  least
  unsigned integer congruent to the source integer (modulo 2n where n is
  the number of bits used to represent the unsigned type).  [Note: In  a
  two's  complement  representation,  this  conversion is conceptual and
  there is no change in the bit pattern (if there is no truncation).  ]

3 If the destination type is signed, the value is unchanged if it can be
  represented  in the destination type (and bit-field width); otherwise,
  the value is implementation-defined.

For enums:

4 If the value true or false is stored into a bit-field of type bool  of
  any  size (including a one bit bit-field), the original bool value and
  the value of the bit-field shall compare equal.  If the  value  of  an
  enumerator is stored into a bit-field of the same enumeration type and
  the number of bits in the bit-field is large enough to  hold  all  the
  values of that enumeration type, the original enumerator value and the
  value of the bit-field shall compare equal.

I think this makes it well defined and the same as C for the DR120 code.