Strange floating point problems on SH4 with gcc 4.1.0

[Andrew de Quincey]

Hi, I have been porting mozilla firefox to the SH4 platform. However, I have 
run into some horrible floating point problems.

details:
gcc 4.1.0
glibc 2.3.6
(built using crosstool)
firefox 1.5.0.4
linux kernel 2.6.11

Running on an STB7100 with SH4-202 processor core (yes it does have an FPU).

I have been trying to make a small test case to illustrate the problem.. but I 
cannot seem to manage it. It seems to be a prerequisite that I must have the 
massive mozilla XPCOM shared libraries loaded or something.

Anyway, I manged to get my test code down to:
int main()
{
//   printf("HELLO\n");
   int x = 20;
   float k = (float) x;
   NS_InitXPCOM2(nsnull, nsnull, nsnull);
   printf("THERE\n");
}

I also have debug prints inside NS_InitXPCOM2.

Basically if I leave the HELLO printf commented out, I do not see the debug in 
NS_InitXPCOM2(). Instead I get a "floating point exception".

If I uncomment it I *do* see the debug (althought it later gets another FP 
exception; this is the problem I'm really trying to solve).

If I comment out the call to NS_InitXPCOM2() it runs fine.

As far as I can make out it is NOT the NS_InitXPCOM2() itself which is failing 
since it outputs my debug if I have the first printf uncommented.

If I add more trace elsewhere the problem sort of shifts about... it sounds 
like some form of alignment problem to me.

Oh, I also tried creating my own shared library with an NS_InitXPCOM5() method 
and calling that instead... that worked fine.

Can anyone advise a way I can try and work out what is going on to provide a 
small example that _doesn't_ involve calling into mozilla XPCOM?

I can always provide the binaries and source if people want it.. but mozilla 
is _huge_.

Oh, my test file was compiled with:
sh4-unknown-linux-gnu-gcc -o TestXPC.o -c -O0 \
           -DMOZILLA_INTERNAL_API -DOSTYPE=\"Linux\" -DOSARCH=\"Linux\" \
           -I../../../../dist/include/xpconnect \
           -I../../../../dist/include/xpcom \
           -I../../../../dist/include/js \
           -I../../../../dist/include/nspr \
           -fPIC \
           /etv/branches/aminet130/scratch/amino-stb710x-mozilla/mozilla/js/src/xpconnect/tests/TestXPC.cpp

and linked with:
sh4-unknown-linux-gnu-gcc \
           -o TestXPC \
           TestXPC.o \
           -L../../../../dist/bin -lxpcom -lxpcom_core \
           -L../../../../dist/lib -lplds4 -lplc4 -lnspr4 \
           -lpthread -ldl  -ldl -lm -lsupc++

I've managed to track down the problem some more with GDB. Even though moving 
calls about seems to move the issue about, it always seems to come from the 
the following GCC function: udivsi3_i4

0x29ae4c50 <__udivsi3_i4+0>:    mov     #1,r1
0x29ae4c52 <__udivsi3_i4+2>:    cmp/hi  r1,r5
0x29ae4c54 <__udivsi3_i4+4>:    bf      0x29ae4c74 <trivial>
0x29ae4c56 <__udivsi3_i4+6>:    rotr    r1
0x29ae4c58 <__udivsi3_i4+8>:    xor     r1,r4
0x29ae4c5a <__udivsi3_i4+10>:   lds     r4,fpul
0x29ae4c5c <__udivsi3_i4+12>:   mova    0x29ae4c78 <L1>,r0
0x29ae4c5e <__udivsi3_i4+14>:   fmov    @r0+,fr5
0x29ae4c60 <__udivsi3_i4+16>:   fmov    @r0,fr4
0x29ae4c62 <__udivsi3_i4+18>:   float   fpul,fr0
0x29ae4c64 <__udivsi3_i4+20>:   xor     r1,r5
0x29ae4c66 <__udivsi3_i4+22>:   lds     r5,fpul
0x29ae4c68 <__udivsi3_i4+24>:   float   fpul,fr2
0x29ae4c6a <__udivsi3_i4+26>:   fadd    fr4,fr0
0x29ae4c6c <__udivsi3_i4+28>:   fadd    fr4,fr2
0x29ae4c6e <__udivsi3_i4+30>:   fdiv    fr2,fr0
0x29ae4c70 <__udivsi3_i4+32>:   rts
0x29ae4c72 <__udivsi3_i4+34>:   ftrc    fr0,fpul

Specifically at:
#0  0x29ae4c6c in __udivsi3_i4 () from 
mozilla/BUILDIT/js/src/xpconnect/tests/mnt/core/lib/libc.so.6

I'm afraid I cannot seem to get anything useful out of gdb (6.3) for the 
floating point register contents. Although I have just noticed the libs are 
nottbuild with debugging on. I'll rebuild the toolchain overnight and see if 
anything more sensible comes out.