I think it can. If you have, say char a; int b; in a struct, so there is padding in between. Then do s.a= x;s.b=y; If x and y happen to have the same memory layout, the compiler can replace the 2 assignements with 1 big transfer, and copy random things in the padding.

Interesting! I guess most realistic scenarios would have x and y on the stack though in which case I bet they'd get optimized out completely under normal circumstances.

True, it is a case of severe bad luck. But these are even worse than normal bugs: Some minor change in an unrelated part of the code triggers a cascade of different inlining decisions, and now a comparison is silently returning wrong answers in a very specific edge case.

Another variant is having x as an int. It is supposed to truncate the int on assignement, but instead it simply dumps the high bits in the alignement.

As the saying goes: Working code > crashing code > silent corruption.