[Bug tree-optimization/77943] [5/6 Regression] Optimization incorrectly commons noexcept calls with non-noexcept calls

["redbeard0531 at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77943

--- Comment #12 from Mathias Stearn <redbeard0531 at gmail dot com> ---
We were hoping to replace many places in our code that does the following with
noexcept attributes on functions:

> try {doStuffThatShouldntThrow();} catch(...) {std::terminate();}

We wanted to take advantage of noexcept preventing exceptions from propagating
in a way that causes the terminate handler to be invoked at the throw site
rather than the catch site. We've avoided doing this so far because of the bugs
that we've found, leaving us with low confidence that we can rely on it. Can
you think of any similar cases that are likely to cause issues? Where do you
think it makes sense to focus our testing?

The scariest issues we've seen were a combination of failures to enforce
noexcept (like this bug) combined with noexcept causing try/catch blocks to be
optimized out. That lead to an exception thrown from a noexcept function
bypassing the surrounding catch block and escaping two layers of protection and
reaching code that really should never see them. Are there any compiler flags
we can use to tell it not to eliminate the catches based on noexcept
annotations?

We've also noticed that 'throw()' annotations have fewer issues, but have
avoided them because they are deprecated. As compiler writers, would you trust
'throw()' more or suggest we stick with noexcept?