It seems that they unified the assembler used in the go compiler to use intrinsics for amd64.
In doing so, they must have botched something, because now some atomic operations (IE. operations that shouldn't be interruptible by another thread) are completely optimized away.
This is quite a big issue because any multi-threaded program will use these (they are the only way to do lock-free code).
This isn't correct, if it was this would be a much bigger issue. I'd be quite surprised if this affects any code in the wild.
This bug is related to the compiler deciding to optimize the loop. All modifications of variables in the loop are being batched till the loop exits, but it never exits therefore none of the modifications ever happen. In most cases this would be fine as the side-effects of modifying the variables in the loop wouldn't need to visible anywhere else until the loop exited.
If you remove the loop and just modify the atomic variable once, the modification is eventually happens and is seen by the second go routine.
In doing so, they must have botched something, because now some atomic operations (IE. operations that shouldn't be interruptible by another thread) are completely optimized away.
This is quite a big issue because any multi-threaded program will use these (they are the only way to do lock-free code).