[PATCH] D27163: Introduce -f[no-]strict-return flag that controls code generation for C++'s undefined behaviour return optimisation

Richard Smith via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 28 14:02:44 PST 2016


rsmith added a comment.

A target-specific default for this, simply because there's a lot of code on Darwin that happens to violate this language rule, doesn't make sense to me.

Basing the behavior on whether a `-Wreturn-type` warning would have been emitted seems like an extremely strange heuristic: only optimizing in the cases where we provide the user no hint that we will do so seems incredibly user-hostile.

Regardless of anything else, it does not make any sense to "return" stack garbage when the return type is a C++ class type, particularly one with a non-trivial copy constructor or destructor. A trap at `-O0` is the kindest thing we can do in that case.

In summary, I think it could be reasonable to have such a flag to disable the trap/unreachable *only* for scalar types (or, at a push, trivially-copyable types). But it seems unreasonable to have different defaults for Darwin, or to look at whether a `-Wreturn-type` warning would have fired.

Alternatively, since it seems you're only interested in the behavior of cases where `-Wreturn-type` would have fired, how about using Clang's tooling support to write a utility to add a return statement to the end of every function where it would fire, and give that to your users to fix their code?


Repository:
  rL LLVM

https://reviews.llvm.org/D27163





More information about the cfe-commits mailing list