From the link, it seems like GCC 8 does not cache a read from a variable, and has more memory access to read it, while GCC 9 reads that variable from a register every time. (Maybe from a corrupted register?)

From what I can tell, the issue is that GCC9 stores the result of a pointer dereference in a register to reuse on each loop operation but the loop operation needs to dereference the pointer each time to work correctly.

Sounds like it needs to be volatile then, or rather whatever atomic memory read the kernel has.

Probably volatile. Likely doesn't need to be atomic, just needs to prevent the compiler from optimizing the code into bugs.

No, it sounds like it needs the kernel not to corrupt the value. There is nothing wrong with leaving the value in the register.

I believe the aforementioned pointer caching is in the kernel--it's the pointer to the FP register state which is cached across preemption points in the kernel.

Ok I see, that's a good point. Was not spelled out this well in the bug tracker comment. (If it is now it wasn't when I read it.)

Probably a mix of both; when developing a kernel, you constantly fight against the compiler trying to be smart and optiziming things out of your code, inlining things, caching data, etc.

In this case, it might be necessary to do a volatile read in case that flag has changed, forcing the compiler to reload it.