On Nov 14, 2017, at 3:21 PM, Joseph Myers <jos...@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.
