https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124218
--- Comment #5 from Chris Copeland <chris.n.copeland at gmail dot com> --- I tried adding __atomic_signal_fence(__ATOMIC_SEQ_CST) to the body of portYIELD(), right after this line: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V11.2.0/portable/GCC/ARM_CM4F/portmacro.h#L96, but the task still gets compiled to an infinite loop, so something still seems wrong here. Here is the same change applied to the original simpler example: https://godbolt.org/z/zbPzeco3c Additionally, the Extended Asm docs (https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html) still contain this language about "memory" clobbers: > Further, the compiler does not assume that any values read from memory before > an asm remain unchanged after that asm; it reloads them as needed. Using the > "memory" clobber effectively forms a read/write memory barrier for the > compiler. If "memory" clobbers do not actually work this way anymore, this should be updated, but I'm not sure what the alternative should be if __atomic_signal_fence(__ATOMIC_SEQ_CST) also doesn't work?
