[Moved to DR at the May, 2015 meeting.]

Proposed resolution (November, 2014):

1. Change 7.2.1 [basic.lval] paragraph 2 as follows:

Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue; see 7.3.2 [conv.lval], 7.3.3 [conv.array], and 7.3.4 [conv.func]. [Note: An attempt to bind an rvalue reference to an lvalue is not such a context; see 9.4.4 [dcl.init.ref]. —end note] [Note: There are no prvalue bit-fields; if a bit-field is converted to a prvalue (7.3.2 [conv.lval]), a prvalue of the type of the bit-field is created, which might then be promoted (7.3.7 [conv.prom]). —end note]

2. Change 7.6.20 [expr.comma] paragraph 1 as follows:

...The type and value of the result are the type and value of the right operand; the result is of the same value category as its right operand, and is a bit-field if its right operand is a glvalue and a bit-field. If the value...

According to 7.6.20 [expr.comma] paragraph 1,

The type and value of the result are the type and value of the right operand; the result is of the same value category as its right operand, and is a bit-field if its right operand is a glvalue and a bit-field.

The description of a bit-field result seems to indicate that the operand might not be a glvalue but could still be a bit-field. There doesn't appear to be a normative prohibition against prvalue bit-fields, so one should presumably be added, and this wording should be adjusted to remove the suggestion that such a thing might exist.