This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

-mno-80387 / -mno-fp-ret-in-387 question


Hello!

I would just like to ask if -mno-fp-ret-in-387 (and now also -mno-80387) violates ABI in some way (just like -mregparm=X). Consider this code:

#include <math.h>

double test(double x) {
double b;
b = sin(x);
return b + 1.0;
}


compiled with gcc -O2 -march=pentium4 -mfpmath=sse -mno-80387:

test:
       pushl   %ebp
       movl    %esp, %ebp
       subl    $24, %esp
       movsd   8(%ebp), %xmm0
       movsd   %xmm0, (%esp)
       call    sin
       movl    %eax, -8(%ebp)
       movl    %edx, -4(%ebp)
       movsd   -8(%ebp), %xmm0
       addsd   .LC1, %xmm0
       movsd   %xmm0, -8(%ebp)
       movl    -8(%ebp), %eax
       movl    -4(%ebp), %edx
       leave
       ret

In this code, it is assumed that sin() function returns its result in %eax/%edx pair. However, a "normal" libm sin() function returns its value in top FP register, so there we have an ABI mismatch. When normal libm is linked with this code, wrong results will be produced.

In -mregparm case, there is a big warning in the documentation:

    *Warning:* if you use this switch, and NUM is nonzero, then you
    must build all modules with the same value, including any
    libraries.  This includes the system libraries and startup modules.

I think that something similar should be added to -mno-fp-ret-in-387 / -m-no-80387.

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]