Am Samstag, den 08.01.2022, 15:41 +0100 schrieb Eric Botcazou: > > Yes, although I think potentially trapping ops > > are not moved before calls (as this would be > > incorrect). So do you think it would be feasable > > to prevent this for volatile too? > > Feasible probably, but why would this be desirable in C? It's not Java!
It would allow us to still give at least some guarantees about the observable behavior of programs that later in their execution encounter UB (e.g. that an transaction with an external device is correctly completed). Considering the fact that it is virtually impossible to prove that any realistic C program is completely free of UB, this is would be very useful. As another example, there was recently the a proposal about adding a safe memory erasure function to the standard lib. It was pointed out that volatile stores would not be enough to be sure that the compiler safely erased some sensitive information, because an optimization based on later UB in the program could undo this. There is now also a proposal for C++ to introduce std::observable, which would require similar ordering constraints. But this would require the programmer to annotate the program correctly. Most C programmers would assume that volatile accesses already provides this guarantee, so actually doing so would be good. Or a more practical example: While debugging some embedded device, it would also be very annoying if the compilers reorders some trap before some debugging output. I could easily imagine loosing hours figuring out what happens. Martin
