On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > But I ran into a compiler divergence on _Generic with bit-field expressions. > My understanding is that _Generic controlling expression undergoes array > to pointer and function to pointer conversions, but not integral promotions > (otherwise it would never match for char, short etc. types). > C23 draft I have says: > "A bit-field is interpreted as having a signed or unsigned integer type > consisting of the specified number of bits" > but doesn't say which exact signed or unsigned integer type that is.
Yes, the type used in _Generic isn't fully specified, just the type after integer promotions in contexts where those occur. > static_assert (expr_has_type (s4.c + 1uwb, _BitInt(389))); > static_assert (expr_has_type (s4.d * 0wb, _BitInt(2))); > static_assert (expr_has_type (s6.a + 0wb, _BitInt(2))); > That looks to me like LLVM bug, because > "The value from a bit-field of a bit-precise integer type is converted to > the corresponding bit-precise integer type." > specifies that s4.c has _BitInt(389) type after integer promotions > and s4.d and s6.a have _BitInt(2) type. Now, 1uwb has unsigned _BitInt(1) > type and 0wb has _BitInt(2) and the common type for those in all cases is > I believe the type of the left operand. Indeed, I'd expect those to pass, since in those cases integer promotions (to the declared _BitInt type of the bit-field, without the bit-field width) are applied. -- Joseph S. Myers jos...@codesourcery.com
