Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding

[Mark Mitchell <mark at codesourcery dot com>]

Michael Matz wrote:

>>>   int i;
>>>   int *p = &i;
>>>   // something
>>>   *p = 3;
>>>
>>> might be invalid.  That seems very wrong.
>> Ok.
> 
> But the above isn't invalid in any of our interpretations of the standard.  
> It will make the object p points to have effective type 'int', whatever 
> was in there before.

It offends my sensibilities, as a long-time student of C and C++, and as
a (not too great) student of programming language theory.  I will not
try to argue that the standard makes this valid or invalid because I
simply do not believe that these issues were fully considered by the
authors; I think it's like arguing about whether or not an arms treaty
written in the time of King Arthur permits the use of nuclear weapons.

> char-array.  A fairly big hammer.  Which doesn't fix the idiom when the 
> author used "int space[8]" (for instance for alignment reasons, or to 
> speed up his copy loop, or whatever) for reserving space.

Yes, but we have alignment attributes for that.  Part of what I'm trying
to do (as with the earlier consensus we hammered out about type-punning
through unions) is to find a way to make the GNU C/C++ languages
sufficiently expressive, but to retain type-safety.  Just as with
type-punning via casts, we can conceivably say "int space[8]" is not a
valid way to get 32 bytes of int-aligned space, but "char space[32]
__attribute__((aligned(__alignof__(int))))" is.

In my ideal world, the ISO C and C++ committees would sit down, work all
this out, and agree on a common model for both languages.  But, that's
not going to happen any time soon.  So, we have to do something in the
mean-time.  Richard's change, together with documentation for our users
that says (as with the type-punning through unions case) what we
consider valid and invalid seems reasonable to me.  And, as in that
case, we might also want -fno-strict-aliasing to mean that the compiler
makes worst-case assumptions about the dynamic type of things randomly
changing so that "int space[8]" code does work, at the expense of
performance.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713