Re: mips gcc -O1: Address exception error on store doubleword
Hi, trying to come up with a testcase we figured out what the problem could be.
When the optimizer is on and memcpy sees that it is copying a struct
with double words in it, it will assume that the struct starts on an 8
byte boundary and use double word loads and stores. This is a safe
assumption, as gcc will always ensure that structs containing doubles
start on an 8 byte boundary when the memory is mallocced.
However we managed to trick gcc by mallocing a large chunk of memory
and then assigning a pointer to a user data (unsigned int user[0])
without first ensuring that the user data was 8 byte aligned. Since
the structure does contain a double, this resulted in a crash in
memcopy.
The fix for this was to inform the compiler that this "void" pointer
should be 8 byte aligned by changing the "unsigned int user[0]" to a
"unsigned long long user[0]". This will cause gcc to pad this entry
out to ensure that it starts on an 8 byte boundary.
Does this make sense?
Alex
On 8/9/07, Alex Gonzalez <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'll try to come up with a short test.
>
> I have narrowed it a bit more. The PVAR structure contains a long long
> variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
> take out the long long variable, the compiler uses sdl instructions
> instead of sd and the exception doesn't happen.
>
> Also, if I do
>
> static void varcopy(void *pvar1, void *pvar2)
>
> the compiler uses sdl and avoids the crash.
>
> I am compiling for n32 ABI, so the register size is 64bits.
>
> Any ideas?
>
> On 8/9/07, David Daney <[EMAIL PROTECTED]> wrote:
> > Alex Gonzalez wrote:
> > > 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?
> > >
> > In order to investigate we would need a self contained test case (i.e.
> > the definition of PVAR must be included). Also it would be nice if you
> > could try it on a current version of GCC (4.2.1 perhaps).
> >
> > David Daney
> >
>
Re: mips gcc -O1: Address exception error on store doubleword
Hi,
I'll try to come up with a short test.
I have narrowed it a bit more. The PVAR structure contains a long long
variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
take out the long long variable, the compiler uses sdl instructions
instead of sd and the exception doesn't happen.
Also, if I do
static void varcopy(void *pvar1, void *pvar2)
the compiler uses sdl and avoids the crash.
I am compiling for n32 ABI, so the register size is 64bits.
Any ideas?
On 8/9/07, David Daney <[EMAIL PROTECTED]> wrote:
> Alex Gonzalez wrote:
> > 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?
> >
> In order to investigate we would need a self contained test case (i.e.
> the definition of PVAR must be included). Also it would be nice if you
> could try it on a current version of GCC (4.2.1 perhaps).
>
> David Daney
>
mips gcc -O1: Address exception error on store doubleword
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():
81024534:27bdffd0 addiusp,sp,-48
81024538:ffbf0020 sdra,32(sp)
8102453c:ffbe0018 sds8,24(sp)
81024540:ffbc0010 sdgp,16(sp)
81024544:03a0f02d moves8,sp
81024548:3c010009 luiat,0x9
8102454c:242108dc addiuat,at,2268
81024550:0039e02d daddugp,at,t9
81024554:afc4 swa0,0(s8)
81024558:afc50004 swa1,4(s8)
8102455c:8fc4 lwa0,0(s8)
81024560:8fc50004 lwa1,4(s8)
81024564:240600a0 lia2,160
81024568:8f99bd08 lwt9,-17144(gp)
8102456c:0320f809 jalrt9
81024570: nop
81024574:03c0e82d movesp,s8
81024578:dfbf0020 ldra,32(sp)
8102457c:dfbe0018 lds8,24(sp)
81024580:dfbc0010 ldgp,16(sp)
81024584:03e8 jrra
81024588:27bd0030 addiusp,sp,48
While the optimized code is:
8101b9d8 :
varcopy():
8101b9d8:24a200a0 addiuv0,a1,160
8101b9dc: nop
8101b9e0:dca3 ldv1,0(a1)
8101b9e4:dca60008 lda2,8(a1)
8101b9e8:dca70010 lda3,16(a1)
8101b9ec:dca80018 lda4,24(a1)
8101b9f0:fc83 sdv1,0(a0)
8101b9f4:fc860008 sda2,8(a0)
8101b9f8:fc870010 sda3,16(a0)
8101b9fc:fc880018 sda4,24(a0)
8101ba00:24a50020 addiua1,a1,32
8101ba04:14a2fff6 bnea1,v0,8101b9e0
8101ba08:24840020 addiua0,a0,32
8101ba0c:03e8 jrra
8101ba10: nop
8101ba14: nop
