[Bug target/53016] memcpy optimization can cause unaligned access on ARM

[jquesnelle at gmail dot com]

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.