[antimagic]

You know what might make it a bit clearer? Showing the assembly code that is associated with each of the boxes. It's hard understanding what each box represents, no-one outside of compiler developers has the right vocabulary for descriptions to work. Something concrete, such as an x86 representation of each boxes actions would make things much clearer.

[sjolsen]

Assembly code would fail to demonstrate the point. The graphs are meant to demonstrate that, temporally speaking, the basic actions being performed by the abstract machine are partially ordered. A consequence of these actions being temporally partially ordered is that two individual actions may be temporally unordered, or "unsequenced." The undefined behaviour comes, roughly speaking, when a "write" action is unsequenced with a "read" or "write" action on the same memory location. This scenario corresponds graphically to a red box and a red/blue box unconnected by any single-direction chain of arrows.

Anyway, the problem with using assembly is that it imposes an artificial temporal total ordering on the actions being performed. Under temporal total ordering, the possibility of unsequenced actions disappears, and the message is lost.

>no-one outside of compiler developers has the right vocabulary for descriptions to work

There's nothing here specific to implementing compilers. There are a few uses of standardese and graph theory, but they're relatively basic concepts that are important to familiarize yourself with if you want to use tools like C++ effectively.