Otherwise, if the second and third operand are glvalue bit-fields
of the same value category and
of types cv1T and cv2T, respectively,
the operands are considered to be of type cvT
for the remainder of this section,
where cv is the union of cv1 and cv2.
Otherwise, if the second and third operand have different types and
either has (possibly cv-qualified) class type, or if both
are glvalues of the same value category and the same type except for
cv-qualification, an attempt is made to
form an implicit conversion sequence from
each of those operands to the type of the other.
Using this process, it is determined whether an implicit conversion
sequence can be formed from the second operand
to the target type determined for the third operand, and vice versa.
If both sequences can be formed, or one can be formed but it is the
ambiguous conversion sequence, the program is ill-formed.
If no conversion sequence can be formed, the operands are left unchanged
and further checking is performed as described below.
Otherwise, if exactly one conversion sequence can be formed,
that conversion is applied to the chosen operand
and the converted operand is used in place of the original operand for
the remainder of this section.
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 and it is a bit-field if the
second or the third operand is a bit-field, or if both are bit-fields.
If the second and third operands do
not have the same type, and either has (possibly cv-qualified) class
type, overload resolution is used to determine the conversions (if any)
to be applied to the operands ([over.match.oper], [over.built]).
If the overload resolution fails, the program is ill-formed.
the conversions thus determined are applied, and the converted operands
are used in place of the original operands for the remainder of this