I figured out why the float -> long long cast wasn't affected by the bug I
found in float -> long cast.  There was a typo in fixsfdi.  The function
name in fixsfdi was __fixsfsi (note the second 's') thus making the linker
bring in that function from libgcc.

Attached is a patch.

Also the patch committed in mulsf.c 1.8 checks to see if both values passed
in are zero.  Was this an intentional compromise between speed and code
size.  If it was shouldn't the check be skipped all together, because
0.0*0.0 is very unlikely (esp because a lot of the time people multiply by
non-zero constants.).

-Chris Takahashi

DIFF:
--- msp430-libc/src/libm/fixsfdi.c      2002-03-29 04:55:15.000000000 -0800
+++ msp430-libc-local/src/libm/fixsfdi.c        2003-08-05
10:33:42.000000000 -0
700
@@ -33,12 +33,13 @@

 extern long long __fixunssfdi(long);

-long long __fixsfsi(long a1)
+long long __fixsfdi(long a1)
 {
        if(!a1) return a1;

        if(a1<0)
        {
+               a1 &= 0x7fffffff;
                return -__fixunssfdi(a1);
        }
        return __fixunssfdi(a1);

Reply via email to