On 8/17/23 3:38 PM, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Thu, Aug 17, 2023 at 7:39 PM Tom Honermann <tom_at_[hidden]> wrote:
>> I agree. Optimizers are not written to take advantage of UB. They are
>> written in accordance with what the standard specifies as defined
>> behavior. When code fails to adhere to what the standard specifies, then
>> optimizers might behave in unexpected ways because a property they rely
>> on (such as the existence of an object of a certain type) has been violated.
>
> There is no invalid bit pattern for an array of int's. Maybe an array
> of float's could have an invalid bit pattern.
> I mean the 'existence of an object' will come down to 0's and 1's at
> the end of it all.

Object representation is distinct from the object model.

How those bits are accessed and used depends on the instructions that
are generated by the compiler. Many optimizations are performed at a
high level with no knowledge of the instruction set. Those optimizations
depend on more abstract concepts like the object model. When the object
model is violated, the guarantees that optimizers rely on are not
present and this can affect the instructions that are later generated.
In particular, the absence of an object could result in no instructions
being emitted at all to load and store those bits. Or the
halt-and-catch-fire instruction might be emitted instead.

I acknowledge the frustration with not being able to treat std::array
and C arrays as interchangeable like this. While the standard *could*
guarantee interoperability, I think it is unlikely that the committee
would be supportive of such direction. Transitioning to use of std::span
in code that currently require a reference to std::array seems like the
easier way forward.

Tom.