https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #13 from Jeffrey A. Law <law at redhat dot com> --- Marc, Yes, absolutely. In fact, I think that falls out of the work Martin S is doing in this space. Conceptually we're looking to generalize that code so that we can route more cases where the compiler detects undefined behavior through the path isolation routines. Within those commonized routines we want to have a knob which selects different behavior from the compiler when undefined behavior is detected which could potentially include issuing the RTL equivalent of __builtin_unreachable vs trap vs warn, but leave the code alone, try to mitigate, etc. Where I think we've differed in the past is what to do with conditional branch upon which the undefined behavior is control dependent upon. As you may remember, the original submission of path isolation would turn that conditional into an unconditional branch to the valid path. That's not correct because there can be observable behavior that occurs on the path from the conditional, but before the undefined behavior triggers. Having a knob to twiddle *that* may or may not be a good idea.
