This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: memcpy to an unaligned address
- From: Shaun Jackman <sjackman at gmail dot com>
- To: Carl Whitwell <carl dot whitwell at gmail dot com>, gcc at sources dot redhat dot com
- Date: Thu, 4 Aug 2005 09:05:56 -0600
- Subject: Re: memcpy to an unaligned address
- References: <345be691050804025955c0b4ab@mail.gmail.com>
- Reply-to: Shaun Jackman <sjackman at gmail dot com>
On 8/4/05, Carl Whitwell <carl.whitwell@gmail.com> wrote:
> Hi,
> thought I'd drop you a mail, would put it on gcc mailing list but
> haven't got time to work out how to send it there at this moment.
The gcc mailing list is gcc@sources.redhat.com.
> All testing here is done on x86 processors using gcc under cygwin.
Are you using an x86 host and an arm target?
> Testing gcc 3.3.4 showed no problems with memcpy alignment. Using your
> example, the structure s was aligned but the member variable b was
> unaligned. The assembler code produced for the direct copy s->a = p and the
> memcpy replacement were identical.
Did it produce an open code memcpy, and was it correct?
> Testing gcc 4.0.1 I found the structure s was unaligned such that the member
> variable b was aligned, which was odd.
> I discovered that the structure appears to be aligned based upon the natural
> alignment of the last element within that structure.
> Of course this means that the memcpy is now acting on an aligned member
> rather than an unaligned member, and works perfectly well.
Interesting. Can you post an assembler snippet of this?
> This means that to cause an unaligned element within the structure I had to
> add another element to the structure and retest.
> On doing this though I found gcc appeared to correctly replace memcpy with
> an unaligned copy.
>
> I completely agree that gcc should be handling all the alignment issues
> here, but I'm not sure what it thinks it's doing moving the structure about
> in 4.0.1
> It may be worth tracking the addresses of the members in all the tests to
> make sure the tests are comparable across gcc versions.
>
> Regards,
> Carl Whitwell
Cheers,
Shaun