On 8/4/05, Carl Whitwell <[EMAIL PROTECTED]> wrote: > Hi, > thought I'd drop you a mail, would put it on gcc mailing list but > haven't got time to work out how to send it there at this moment.
The gcc mailing list is [EMAIL PROTECTED] > All testing here is done on x86 processors using gcc under cygwin. Are you using an x86 host and an arm target? > Testing gcc 3.3.4 showed no problems with memcpy alignment. Using your > example, the structure s was aligned but the member variable b was > unaligned. The assembler code produced for the direct copy s->a = p and the > memcpy replacement were identical. Did it produce an open code memcpy, and was it correct? > Testing gcc 4.0.1 I found the structure s was unaligned such that the member > variable b was aligned, which was odd. > I discovered that the structure appears to be aligned based upon the natural > alignment of the last element within that structure. > Of course this means that the memcpy is now acting on an aligned member > rather than an unaligned member, and works perfectly well. Interesting. Can you post an assembler snippet of this? > This means that to cause an unaligned element within the structure I had to > add another element to the structure and retest. > On doing this though I found gcc appeared to correctly replace memcpy with > an unaligned copy. > > I completely agree that gcc should be handling all the alignment issues > here, but I'm not sure what it thinks it's doing moving the structure about > in 4.0.1 > It may be worth tracking the addresses of the members in all the tests to > make sure the tests are comparable across gcc versions. > > Regards, > Carl Whitwell Cheers, Shaun
