https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70285
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In particular, we hit the
/* [expr.cond]
If the second and third operands are glvalues of the same value
category and have the same type, the result is of that type and
value category. */
if (((real_lvalue_p (arg2) && real_lvalue_p (arg3))
|| (xvalue_p (arg2) && xvalue_p (arg3)))
&& same_type_p (arg2_type, arg3_type))
{
result_type = arg2_type;
arg2 = mark_lvalue_use (arg2);
arg3 = mark_lvalue_use (arg3);
goto valid_operands;
}
case, and therefore bypass any promotion.
As I said, arg2 has type signed char, arg2_type is int, arg3 has type int and
arg3_type is int.
So, the question is what C++ says here we should do with the bitfields.
Shall it call same_type_p (TREE_TYPE (arg2), TREE_TYPE (arg3)) instead? Saying
that int :8 bitfield has the same type as int is just weird.
But, what would happen if both arms are say the int :8 bitfields? The result
type will be still int, different from the arm types.
Let's CC Jason on this.
