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

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D27163#607100, @rsmith wrote:

> In https://reviews.llvm.org/D27163#607078, @rsmith wrote:
>
> > 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.
>
>
> ... but rjmccall's explanation of the problem helps. The C compatibility argument also suggests that this should only apply to trivially-copyable types, and perhaps only scalar types.


I would agree with this.  The right rule is probably whether the type is trivially-destructed.

> The same issue presumably arises for `-fstrict-enums`, which is again only UB in C++? (Also, C has rather different and much less useful TBAA rules.) Perhaps some catch-all "I want defined behavior for things that C defines even though I'm compiling in C++" flag would make sense here?

I don't think we've seen problems from any of these.  Also I don't think the TBAA rules are as different as you're suggesting, except that C++ actually tries to provide specific rules for unions (that don't match what users actually want).


Repository:
  rL LLVM

https://reviews.llvm.org/D27163