https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to nfxjfg from comment #7) > > Note also the order of the writes to reg1 and reg2 might happen in a > > different order in HW so you need to have a full (HW) write barrier between > > them to make sure the write is done in the correct order. > > Seriously? That breaks literally all code that uses volatile for register > access (which, in our firmwares, is ALL code). This just fuels my belief > that gcc and C compiler developers in general turned C into a useless, > fragile language that can't do anything correctly. > > Is there a way to prevent reordering of volatile accesses? Yes you need to use inline-asm to get a hw write barrier. This has been this way for the last 20+ years even when it comes to out of order processors. https://www.puppetmastertrading.com/images/hwViewForSwHackers.pdf should be very useful. Basically volatile means the compiler not to remove the store/load from it but it does not mean the HW will reorder the stores/loads. Oh and GCC even documents part of this: https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html "Accesses to non-volatile objects are not ordered with respect to volatile accesses. You cannot use a volatile object as a memory barrier to order a sequence of writes to non-volatile memory. " The documentation does not mention hw memory barriers since that is outside of the compiler view really. This has been standard behavior with GCC and hardware with weak memory systems for over 20 years. That is even if GCC outputs the writes in order in the assembly the hardware (or future hardware depending on the definition of the hardware) might reorder the writes. RISCV IIRC has both a weak and strong memory consistency models. https://riscv.org/wp-content/uploads/2018/05/14.25-15.00-RISCVMemoryModelTutorial.pdf for more details on it. GCC will never output the needed instructions directly.
