https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
Paul McKenney <paulmckrcu at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |paulmckrcu at gmail dot com
--- Comment #3 from Paul McKenney <paulmckrcu at gmail dot com> ---
Expanding on Martin's description...
The volatile write's device semantics are unknown to the compiler. Those
semantics can include generating a trap. This trap need not return, for
example, it could resume execution in a different place via
setjump()/longjump(). The overall design (including the
unknown-to-the-compiler device semantics) might guarantee that when b is equal
to zero, execution will resume somewhere else, that is, the trap handler is
guaranteed not to return in that case.
And this is one reason why possibly trapping operations must not be moved
across volatile accesses. Doing so breaks device drivers.
