Proposed resolution:

This wording is relative to N5054.

1. Modify [bit.cast] as indicated:

   template<class To, class From>
     constexpr To bit_cast(const From& from) noexcept;
   

   -1- Constraints:

   […]

   -?- Mandates: is_volatile_v<From> is `false`.

   -2- Constant When: Neither `To` nor `From` has constexpr-unknown representation ([expr.const.core]).

From [bit.cast], it is unclear how `std::bit_cast` interacts with various expectations around "volatile access". For example, the `std::bit_cast` wording does not identify what access operation is being performed to inspect the object representation of `from`. Therefore, it is firstly unclear whether there is any volatile access at all, and secondly unclear whether there may be multiple volatile accesses (e.g., one per byte of the object representation).

This interacts with the undefined behaviour specified by [dcl.type.cv] p5 to occur when an attempt is made to access an object defined with a volatile-qualified type through the use of a non-volatile glvalue. Such undefined behaviour is backed by implementation concerns such as the possible need to use corresponding load instructions in the case of certain memory-mapped registers, where even using another load instruction for the same width may trigger a hardware exception. Therefore, approaches that try to access `from` in a non-volatile manner or byte-wise are problematic.

This also interacts with the undefined behaviour specified by [conv.lval] bullet (3.3) for when lvalue-to-rvalue conversion occurs for an object whose value representation is not valid for its type. This raises a problem for approaches that try to access `from` as a glvalue of its declared type. Such an approach has the additional problem that the load instructions involved for such a volatile access may not preserve the value representation, which may be observable by a program if the object was not actually volatile.