[Bug c++/70285] [6 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70285

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> 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.

C++ says that the ?: expression is a bit-field lvalue of type int.  Explicitly
promoting arg2 to int would cause it to no longer be an lvalue.  I'm not sure
how it makes sense to represent this; lowered bit-field types really complicate
matters.