This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: memcpy to an unaligned address


>>>>> "Shaun" == Shaun Jackman <sjackman@gmail.com> writes:

 Shaun> On 8/2/05, Paul Koning <pkoning@equallogic.com> wrote:
 >> It sounds like the workaround is to avoid memcpy, and just use
 >> variable assignment.  Alternatively, cast the pointers to char*,
 >> which should force memcpy to do the right thing.  Ugh.

 Shaun> I swear originally, back in the gcc 2.95 days, I used memcpy
 Shaun> because the memcpy function checked for unaligned pointers,
 Shaun> whereas storing to and loading from unaligned variables
 Shaun> generated a simple store/load instruction which wouldn't
 Shaun> work. It seems the tables have turned and the exact opposite
 Shaun> is true now with gcc 4, where memcpy doesn't work, but
 Shaun> unaligned variables do. I believe gcc 3 behaved the same as
 Shaun> gcc 2 -- memcpy worked, unaligned variables didn't work. Can
 Shaun> someone confirm this summary is correct?

I'm pretty sure I have used unaligned load/store with gcc 2 as well as
3 and it works correctly.  Certainly it should work correctly.  If you
tell GCC to pack stuff, and it does (assigning odd offsets in the
process) then GCC is responsible for generating code to cope with
that.  All this assuming you're not playing games with pointer
arithmetic to generate pointers that are less aligned than what GCC is
entitled to assume.  If you saw something else, that would have been a
GCC bug.

    paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]