This is underspecified. The issue of what the standard means when it refers to bit-wise operations is the subject of a few defect reports.
For example defect report 1857: Additional questions about bits:
The specification of the bitwise operations in 5.11 [expr.bit.and],
5.12 [expr.xor], and 5.13 [expr.or] uses the undefined term “bitwise” in describing the operations, without specifying whether it is the
value or object representation that is in view.
Part of the resolution of this might be to define “bit” (which is
otherwise currently undefined in C++) as a value of a given power of
2.
and the response was:
CWG decided to reformulate the description of the operations
themselves to avoid references to bits, splitting off the larger
questions of defining “bit” and the like to issue 1943 for further
consideration.
and defect report 1943 says:
CWG decided at the 2014-06 (Rapperswil) meeting to address only a
limited subset of the questions raised by issues 1857 and 1861. This
issue is a placeholder for the remaining questions, such as defining a
“bit” in terms of a value of 2n, specifying whether a bit-field has a
sign bit, etc.
We can see from this defect report 1796: Is all-bits-zero for null characters a meaningful requirement?, that this issue of what the standard means when it refers to bits affected/affects other sections as well:
According to 2.3 [lex.charset] paragraph 3,
The basic execution character set and the basic execution wide-character set shall each contain all the members of the basic
source character set, plus control characters representing alert,
backspace, and carriage return, plus a null character (respectively,
null wide character), whose representation has all zero bits.
It is not clear that a portable program can examine the bits of the
representation; instead, it would appear to be limited to examining
the bits of the numbers corresponding to the value representation
(3.9.1 [basic.fundamental] paragraph 1). It might be more appropriate
to require that the null character value compare equal to 0 or ''
rather than specifying the bit pattern of the representation.
There is a similar issue for the definition of shift, bitwise and, and
bitwise or operators: are those specifications constraints on the bit
pattern of the representation or on the values resulting from the
interpretation of those patterns as numbers?
In this case the resolution was to change:
representation has all zero bits
to:
value is 0.
Note that as mentioned in ecatmur's answer the draft C++ standard does defer to C standard section 5.2.4.2.1
in section 3.9.1
[basic.fundamental] in paragraph 3
it does not refer to section 6.5/4
from the C standard which would at least tell us that the results are implementation defined. I explain in my comment below that C++ standard can only incorporate text from normative references explicitly.