Richard Henderson <[EMAIL PROTECTED]> writes: > On Tue, Aug 02, 2005 at 01:45:01PM -0700, Ian Lance Taylor wrote: > > Andrew Pinski <[EMAIL PROTECTED]> 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
