This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: memcpy to an unaligned address
- From: Richard Henderson <rth at redhat dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, Mike Stump <mrs at apple dot com>, Dave Korn <dave dot korn at artimi dot com>, Paul Koning <pkoning at equallogic dot com>, gcc at sources dot redhat dot com, Shaun Jackman <sjackman at gmail dot com>
- Date: Wed, 3 Aug 2005 11:00:11 -0700
- Subject: Re: memcpy to an unaligned address
- References: <200508022037.j72Kbr4T012558@earth.phy.uc.edu> <m3mzo0jcfm.fsf@gossamer.airs.com>
On Tue, Aug 02, 2005 at 01:45:01PM -0700, Ian Lance Taylor wrote:
> Andrew Pinski <pinskia@physics.uc.edu> writes:
>
> > > 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.
> >
> > No it is not, once you take the address (which should be rejected), it
> > is of type "unsigned int *" and not unaligned variable, passing it to
> > memcpy assumes the type alignment is the natural alignment.
>
> That argument doesn't make sense to me.
It is nevertheless correct. Examine all of the parts of the expression.
In particular, "&s->b". What type does it have? In an ideal world, it
would be "pointer to unaligned integer". But we have no such type in
our type system, so it is "pointer to integer". This expression is ONLY
THEN passed to memcpy. At which point we query the argument for its
alignment, and get the non-intuitive result.
If you instead pass "s" to memcpy, you should get the correct unaligned
copy. If that isn't happening, that's a bug.
r~