Hi, I am seeing an address error exception caused by the gcc optimizer -O1.
I have narrowed it down to the following function: static void varcopy(PVAR *pvar1, PVAR *pvar2) { memcpy(pvar1,pvar2,sizeof(PVAR)); } Being the sizeof(PVAR) 160 bytes. The exception is caused on an sd instruction when the input is not aligned on a doubleword boundary. I was under the assumption that the compiler made sure that it doesn't store a doubleword that is not aligned on a doubleword boundary. Is this a bug in the optimizer? I am using a gcc mips64 cross-compiler, mips64-linux-gnu-gcc (GCC) 3.3-mips64linux-031001 Has anyone experienced this problem before? Regards, Alex ------------------------------------------------------- For reference, The resulting code without optimizing is: 81024534 <varcopy>: varcopy(): 81024534: 27bdffd0 addiu sp,sp,-48 81024538: ffbf0020 sd ra,32(sp) 8102453c: ffbe0018 sd s8,24(sp) 81024540: ffbc0010 sd gp,16(sp) 81024544: 03a0f02d move s8,sp 81024548: 3c010009 lui at,0x9 8102454c: 242108dc addiu at,at,2268 81024550: 0039e02d daddu gp,at,t9 81024554: afc40000 sw a0,0(s8) 81024558: afc50004 sw a1,4(s8) 8102455c: 8fc40000 lw a0,0(s8) 81024560: 8fc50004 lw a1,4(s8) 81024564: 240600a0 li a2,160 81024568: 8f99bd08 lw t9,-17144(gp) 8102456c: 0320f809 jalr t9 81024570: 00000000 nop 81024574: 03c0e82d move sp,s8 81024578: dfbf0020 ld ra,32(sp) 8102457c: dfbe0018 ld s8,24(sp) 81024580: dfbc0010 ld gp,16(sp) 81024584: 03e00008 jr ra 81024588: 27bd0030 addiu sp,sp,48 While the optimized code is: 8101b9d8 <varcopy>: varcopy(): 8101b9d8: 24a200a0 addiu v0,a1,160 8101b9dc: 00000000 nop 8101b9e0: dca30000 ld v1,0(a1) 8101b9e4: dca60008 ld a2,8(a1) 8101b9e8: dca70010 ld a3,16(a1) 8101b9ec: dca80018 ld a4,24(a1) 8101b9f0: fc830000 sd v1,0(a0) 8101b9f4: fc860008 sd a2,8(a0) 8101b9f8: fc870010 sd a3,16(a0) 8101b9fc: fc880018 sd a4,24(a0) 8101ba00: 24a50020 addiu a1,a1,32 8101ba04: 14a2fff6 bne a1,v0,8101b9e0 <varcopy+0x8> 8101ba08: 24840020 addiu a0,a0,32 8101ba0c: 03e00008 jr ra 8101ba10: 00000000 nop 8101ba14: 00000000 nop