http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
Jeffrey Quesnelle <jquesnelle at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | --- Comment #4 from Jeffrey Quesnelle <jquesnelle at gmail dot com> 2012-04-17 16:34:12 UTC --- That may be the case for something like an operator=, but memcpy takes a void* (an opaque stream of bytes). In fact, I originally had an used operator= here which caused a SIGBUS, which was reasonable. Given such a problem, the solution is clearly "well it's unaligned, use a memcpy", which is what I did. In -O2 however the behavior is essentially equivalent to an operator=, but memcpy was exactly the solution needed to get away from the problem created by using an operator=! In the memcpy line in the test case, I even have casts to (void*) and (const void *). I would argue that the compiler is not entitled to treat a memcpy as if it were an operator= when manual pointer arithmetic and direct casts to the opaque byte type imply that we don't want a member-by-member copy but rather a byte-by-byte copy. Crucially, memcpy is likely to be used exactly at times when this behavior is needed. Reverting to unconfirmed. If you still disagree with my argument revert back to invalid, but I wanted to explain how this code can (and was) written from a reasonable thought process and as such could reasonably be expected to work. As a side note, this problem doesn't in G++ if reinterpret_cast<> is used on the arguments to memcpy.