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

[Richard Smith via cfe-commits]

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

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

Sure, but effective types are only checked when the stored value is
accessed, which doesn't happen when naming a member of a struct or union,
only at the subsequent assignment or lvalue conversion, at which point the
lvalue expression has the type of the accessed subobject, so is presumably
valid per C11 6.5/7. (The lvalue expression won't have the type of some
enclosing struct here regardless of whether you used that struct type to
form an lvalue designating one of its members.)

If we really were supposed to imagine all objects enclosing the accessed
object for the purpose of C11 6.5/7, it's missing a rule allowing an lvalue
expression whose type is a member of the effective type of the object to
access the object. (It has the opposite rule, in order to allow accesses of
lvalues denoting entire structs to access the values stored in scalar
subobjects.)

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

Agreed :)


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

Interesting. What I see from users is a strong desire to be able to do
bitwise reinterpretation of values /somehow/, not necessarily to type-pun
through unions, which I think is subtly but importantly different. The C
DRs list has some implication that the C committee at some point intended
to make type-punning through unions work, but failed to actually make the
necessary changes in the wording (and all that we have left is a footnote).

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

I've seen plenty of programs that would be valid under some interpretations
of C's rules, but not under C++'s rules. But since we effectively provide
the C++ rules in all cases regardless, I agree this is not relevant for the
issue at hand.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161128/e0bb5ad2/attachment-0001.html>