Re: memcpy to an unaligned address

[Ian Lance Taylor <ian at airs dot com>]

Richard Henderson <rth@redhat.com> writes:

> 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.

That's a good explanation for what gcc is doing, and I do now
understand better than I did before.  But I thought Andrew was arguing
that gcc's behaviour is correct, and is not a compiler bug.  I still
think that gcc's behaviour here is not correct.  It is clear that if
gcc did not open code memcpy, the right thing would happen.  If gcc
open codes memcpy in such a way that it makes an incorrect assumption
about alignment, for whatever reason, I think that is a bug in the
compiler.

And so, since I think this is a bug which we want to fix, and since we
obviously want gcc to open code memcpy, I think that gcc has to
somehow notice the memory alignments involved.

Ian