Re: memcpy() optomization issue

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.LNX.4.04.9904121342460.15391-100000@fluffy.aphrodite.com>you
 write:
  > I guess this could be considered either a bug or a feature, but the
  > circumstance surrounding it is curious.
  > 
  > Using gnu-as (binutils 2.9.1) and egcs-2.91.60, there is a very wierd
  > gotcha with memcpy() optomizations on -O2.
  > 
  > Consider a pointer to structure assigned to a non-aligned memory space. A
  > memcpy() of 4 bytes will optomize to an assignment (as I would expect; how
  > is the compiler to know the structure isn't pointing to an aligned
  > address?).  On Solaris 2.6 and Hpux 10.20, both of which are non-intel
  > architectures which care about alignment, this causes an obvious problem.
  > 
  > The wierd thing is this doesn't happen if -pipe isn't used as a compiler
  > option.  That is, -O2 -pipe causes an aligment execption, while -O2
  > doesn't, however both versions compile to the same assembly output, as far
  > as I can tell.  This to me is wierd.
  > 
  > This does have an obious workaround; in my case I wrote a copy4()
  > function which performs the copy without using memcpy().
  > 
  > But given that a programmer will use a memcpy() of 4 bytes explicitly to
  > NOT cause an alignment exepction, is this really a sensible optomization?
We would need a testcase.

The compiler knows about the alignment of items and isn't supposd to combine
memory accesses if it is not safe to do so.

The fact that it only fails with -pipe would indicate that the problem is
likely more subtle -- memory corruption or some such causing the compiler to
generate incorrect code.  ie, -pipe should have absolutely no effect on the
generated code.

jeff