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

[Richard Smith via cfe-commits]

(Dropping Phabricator, since this isn't really about D27163...)

On 28 November 2016 at 14:27, John McCall via Phabricator via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> In https://reviews.llvm.org/D27163#607100, @rsmith wrote:
> > C has rather different and much less useful TBAA rules
>
> [...] I don't think the TBAA rules are as different as you're suggesting,


I can offhand think of at least the following differences, some of which
seem fairly major:
 * C does not allow changing the effective type of a declared variable, C++
does.
 * C does not support struct-path TBAA in any form (its model is that lumps
of memory have effective types, and it doesn't care how you got there), C++
does.
 * C allows any assignment to a union member to change the effective type,
no matter whether it's locally determinable that you're storing to a union
member, C++ requires the assignment's LHS to be a union member access.
 * C only permits common initial sequence shenanigans for unions where the
union type is visible, C++ permits it anywhere.


> except that C++ actually tries to provide specific rules for unions (that
> don't match what users actually want).


In what way don't C++'s union rules match user expectations where C's rules
do? Do you mean type punning via unions? C doesn't allow that either (or
maybe it does, if you think a footnote carries more normative weight than
rules in the main text).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161128/d1a5c794/attachment.html>