On 12/09/14 23:58, haynberg@xxxxxxxxx wrote: >> Firstly, char types alias everything. > (I'm not sure why you wrote that?) Because the specification says so. 6.3.2.3, Pointers, in C9X. > I know if you cast to char type, > it can, but I'm going from a char type. > >> Secondly, even if you call memcpy(), a compiler doesn't have to do any >> copies if it can prove that the union you're reading into doesn't >> escape. > If the compiler can optimize away memcpy, why memcpy into a union, why > not just to the type in question? Or is memcpy into a union special? You can copy the bytes from one object to another, and it has the same effect. I can't guarantee it generates the same code as a union in all cases. > In other words, if I write: > > msg p; > memcpy(&p, get_bytes(), sizeof p); // assume the size OK > if (p.i) > // ... > > Can the memcpy be optimized away, making it similar to the cast version > (but not undefined)? Sure. Try it. >>> Putting alignment/padding concerns aside > FYI, I meant assume I'm on x86, or hardware that allows unaligned reads, > and my struct doesn't have padding issues. For example, sending a pragma > packed struct over a socket. > >>> Another related, maybe more important, question is if GCC sees a >>> reinterpet_cast like this (without a may_alias type), is it free to >>> discard code or otherwise drastically change it due to the fact that >>> it’s undefined by the standard? >> >> Yes. It may, and it does. > At some point, I understand GCC began to optimize more heavily in > strict-aliasing opportunities. For future reference, when GCC makes > changes like this, are they always mentioned in the release notes or > someplace else? Not AFAIK. We take the view that GCC is free to optimize as much as possible, subject to the constraints of the language. And, of course, we can't always predict what an optimization might do to every buggy program. Andrew.
