From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18411 invoked by alias); 4 Aug 2005 15:06:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18031 invoked by uid 22791); 4 Aug 2005 15:05:57 -0000 Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.206) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 04 Aug 2005 15:05:57 +0000 Received: by rproxy.gmail.com with SMTP id i8so354626rne for ; Thu, 04 Aug 2005 08:05:56 -0700 (PDT) Received: by 10.11.99.12 with SMTP id w12mr11302cwb; Thu, 04 Aug 2005 08:05:56 -0700 (PDT) Received: by 10.11.99.47 with HTTP; Thu, 4 Aug 2005 08:05:56 -0700 (PDT) Message-ID: <7f45d93905080408053411888b@mail.gmail.com> Date: Thu, 04 Aug 2005 15:06:00 -0000 From: Shaun Jackman Reply-To: Shaun Jackman To: Carl Whitwell , gcc@sources.redhat.com Subject: Re: memcpy to an unaligned address In-Reply-To: <345be691050804025955c0b4ab@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <345be691050804025955c0b4ab@mail.gmail.com> X-SW-Source: 2005-08/txt/msg00150.txt.bz2 On 8/4/05, Carl Whitwell wrote: > Hi,=20 > 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.=20 The gcc mailing list is gcc@sources.redhat.com. =20=20=20 > All testing here is done on x86 processors using gcc under cygwin.=20 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 =3D p and= the > memcpy replacement were identical.=20 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 mem= ber > variable b was aligned, which was odd.=20 > I discovered that the structure appears to be aligned based upon the natu= ral > alignment of the last element within that structure.=20 > Of course this means that the memcpy is now acting on an aligned member > rather than an unaligned member, and works perfectly well.=20 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.=20 > On doing this though I found gcc appeared to correctly replace memcpy with > an unaligned copy.=20 >=20=20=20 > 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 abo= ut > in 4.0.1=20 > It may be worth tracking the addresses of the members in all the tests to > make sure the tests are comparable across gcc versions.=20 >=20=20=20 > Regards,=20 > Carl Whitwell=20 Cheers, Shaun