czw., 17 sie 2023 o 21:55 Jonathan Wakely via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> On Thu, 17 Aug 2023 at 20:38, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> 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.
>
>
> No it won't, because the C++ language is defined by the rules of the abstract machine, not your CPU. If you want to write assembly code and deal only with 0s and 1s, do that, stop wasting our time with ideas for C++.
>

Even more, there was already "production code" bugs that happen
because some programs lie to the compiler.
Probaby type aliasing rules are the biggest culprit here as it affects
generated code in tight loops.
If compiler see two unrelated types X and Y then when you update X,
compiler will not bother with
refreshing Y as he know that it can't overlap. But if X and Y occupy
the same memory then a lot of fun happens
when the compiler use stale data in the next step.

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals