From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-118002-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 27863 invoked by alias); 2 Aug 2005 20:29:50 -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 27741 invoked by uid 22791); 2 Aug 2005 20:29:45 -0000
Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 02 Aug 2005 20:29:45 +0000
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j72KThlW017610
	for <gcc@sources.redhat.com>; Tue, 2 Aug 2005 13:29:43 -0700 (PDT)
Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.3.17) with ESMTP id <T7283cae192118064cc37c@mailgate2.apple.com>;
 Tue, 2 Aug 2005 13:29:43 -0700
Received: from [17.201.24.155] (mrs.apple.com [17.201.24.155])
	by relay2.apple.com (8.12.11/8.12.11) with ESMTP id j72KTek4027060;
	Tue, 2 Aug 2005 13:29:41 -0700 (PDT)
In-Reply-To: <7f45d93905080213152a54106c@mail.gmail.com>
References: <7f45d9390508021226ea16fc7@mail.gmail.com> <SERRANObDBRArVc4Iu1000000e0@SERRANO.CAM.ARTIMI.COM> <7f45d93905080213152a54106c@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <78966CDA-DC9F-46F5-AE63-563051D9EF3C@apple.com>
Cc: Dave Korn <dave.korn@artimi.com>, Paul Koning <pkoning@equallogic.com>,
        gcc@sources.redhat.com
Content-Transfer-Encoding: 7bit
From: Mike Stump <mrs@apple.com>
Subject: Re: memcpy to an unaligned address
Date: Tue, 02 Aug 2005 20:29:00 -0000
To: Shaun Jackman <sjackman@gmail.com>
X-SW-Source: 2005-08/txt/msg00083.txt.bz2

On Aug 2, 2005, at 1:15 PM, Shaun Jackman wrote:
> There is no padding. The structure is defined as
> __attribute__((packed)) to explicitly remove the padding. The result
> is that gcc knows the unaligned four byte member is at an offset of
> two bytes from the base of the struct, but uses a four byte load at
> the unaligned address of base+2. I don't expect...
>     p->unaligned = n;
> ... to work,

Actually, that works just fine, with:

typedef struct {
   unsigned short int a;
   unsigned int b;
} __attribute__((packed)) st;

void foo(st *s, int n)
{
   s->b = n;
}

I get:

_foo:
         @ args = 0, pretend = 0, frame = 0
         @ frame_needed = 0, uses_anonymous_args = 0
         @ link register save eliminated.
         mov     r3, r1, lsr #24
         mov     r2, r1, lsr #8
         mov     ip, r1, lsr #16
         @ lr needed for prologue
         strb    r3, [r0, #5]
         strb    r2, [r0, #3]
         strb    ip, [r0, #4]
         strb    r1, [r0, #2]
         mov     pc, lr

> but I definitely expect
>     memcpy(&p->unaligned, &n, sizeof p->unaligned);
> to work.

Ah, I was having trouble getting it to fail for me...  Now I can:

#include <memory.h>

typedef struct {
   unsigned short int a;
   unsigned int b;
} __attribute__((packed)) st;

void foo(st *s, int n)
{
   memcpy(&s->b, &n, sizeof n);
}

_foo:
         @ args = 0, pretend = 0, frame = 4
         @ frame_needed = 0, uses_anonymous_args = 0
         @ link register save eliminated.
         sub     sp, sp, #4
         @ lr needed for prologue
         str     r1, [r0, #2]
         add     sp, sp, #4
         bx      lr

Yes, this is a compiler bug in the expansion of memcpy, please file a  
bug report.  The solution is for the compiler to notice the memory  
alignment of the destination and `do-the-right-thing' when it isn't  
aligned.