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

[John McCall via cfe-commits]

On Mon, Nov 28, 2016 at 2:48 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> (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.
>

Well, except that the name of the variable itself becomes formally unbound
to an object, no?  But yes, you can change the effective type via an alias
as long as you're careful to only use it through that alias, which is not
permitted in C.


>  * 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.
>

You're assuming that a lump of memory can't have multiple effective types
at once due to subobject overlap, which doesn't seem justified by the
text.  In particular, a variable of struct type definitely has the
effective type of that struct.


>  * 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.
>

The union rules in C are all over the place.  I gave up trying to pretend
that C has consistent union semantics a long time ago.


> 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).
>

I was careful to say "what users actually want".  Users *want* type punning
via unions. C's rules are contradictory because, as I read it, the
committee has never been able to come to a consensus about how to formalize
allowing type punning via unions without breaking the entire model — and to
be fair, I don't know how to do that either.  But I would say that the
expressed user desires are pretty clear here.

Anyway, this is not actually important here, and I have not seen any code
that falls into the cracks between language standards here, at least not
under LLVM's intentionally-more-permissive-than-standardized application of
TBAA.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161128/8a673c88/attachment.html>