From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-118014-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30597 invoked by alias); 2 Aug 2005 22:26:00 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 30511 invoked by uid 22791); 2 Aug 2005 22:25:56 -0000
Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.197)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 02 Aug 2005 22:25:56 +0000
Received: by rproxy.gmail.com with SMTP id a36so2161448rnf
        for <gcc@sources.redhat.com>; Tue, 02 Aug 2005 15:25:54 -0700 (PDT)
Received: by 10.11.99.3 with SMTP id w3mr265cwb;
        Tue, 02 Aug 2005 15:25:54 -0700 (PDT)
Received: by 10.11.99.15 with HTTP; Tue, 2 Aug 2005 15:25:54 -0700 (PDT)
Message-ID: <7f45d9390508021525612903a3@mail.gmail.com>
Date: Tue, 02 Aug 2005 22:26:00 -0000
From: Shaun Jackman <sjackman@gmail.com>
Reply-To: Shaun Jackman <sjackman@gmail.com>
To: Paul Koning <pkoning@equallogic.com>
Subject: Re: memcpy to an unaligned address
Cc: pinskia@physics.uc.edu, mrs@apple.com, dave.korn@artimi.com, 
	gcc@sources.redhat.com
In-Reply-To: <17135.56182.648000.413121@gargle.gargle.HOWL>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <78966CDA-DC9F-46F5-AE63-563051D9EF3C@apple.com>
	 <200508022037.j72Kbr4T012558@earth.phy.uc.edu>
	 <17135.56182.648000.413121@gargle.gargle.HOWL>
X-SW-Source: 2005-08/txt/msg00095.txt.bz2

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.

Casting to void* does not work either. gcc keeps the alignment
information -- but not the *unalignment* information, if that
distinction makes any sense -- of a particular variable around as long
as it can, through casts and even through assignment. The unalignment
information, on the other hand, is lost immediately after the &
operator. None of these examples produce an unaligned load:

	memcpy(&s->b, &n, sizeof n);

	memcpy((void*)&s->b, &n, sizeof n);

	void *p =3D &s->b;
	memcpy(p, &n, sizeof n);

But as pointed out by others, this does produce an unaligned load:

	s->b =3D n;

Cheers,
Shaun