[PATCH] D79507: [flang] Change DIE("unreachable") cases to use llvm_unreachable

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 28 17:38:25 PDT 2020


dblaikie added a comment.

In D79507#2061428 <https://reviews.llvm.org/D79507#2061428>, @klausler wrote:

> In D79507#2055514 <https://reviews.llvm.org/D79507#2055514>, @DavidTruby wrote:
>
> > The runtime behaviour when compiled with RELEASE is undefined. As I and @hfinkel mentioned, the point of that is optimisations that cannot otherwise be made by the compiler. I would say that runtime performance of release builds should be one of our main priorities...
>
>
> Release builds of the compiler must have well-defined behavior, and that behavior must be to crash on a fatal internal error rather than to silently proceed to generate incorrect code, which is the worst thing a compiler can do to a user.  Trading off protection against silent generation of bad code to gain some unmeasured performance improvement would be insanely irresponsible.


That seems inconsistent with the way Clang is written (are you suggesting Clang is "insanely irresponsible" - or that many/most other software that uses assertions that are no-op'd in release builds are so?), which seems like a counterproof. Indeed it's impossible to test all invariants at all times in C++ - so which ones do we test? Do we test/fatal-error all array accesses? (do we test them at every layer of API abstraction - because a caller might violate the contract at any layer?).  It doesn't seem practical to create such software - we make assumptions that code behaves according to its contract all the time & should continue to do so.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79507/new/

https://reviews.llvm.org/D79507





More information about the llvm-commits mailing list