On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote:
> Okay, I must be losing my mind. Does anyone know why the following
> program compiled with stock gcc-3.2.1, stock CFLAGS, and no CPUTYPE
> produces:
>
> ddy.quot = 1
> ddy.rem = -1077937744
>
> on -CURRENT, and:
>
> ddy.quot = 8
> ddy.rem = 0
>
> On -stable?
>
> #include <stdlib.h>
> #include <stdio.h>
>
> main(void) {
> div_t ddy;
> int dy, dy_frac;
>
> ddy = div (768, 96);
> dy = ddy.quot;
> dy_frac = ddy.rem;
>
> printf("ddy.quot = %d\n", dy);
> printf("ddy.rem = %d\n", dy_frac);
>
> return 0;
> }
>
> > cc -O -pipe -o xxx xxx.c
>
> I'm doing something wrong, right? I mean, this can't be right. I've
> verified this now on a P4 running:
[...]
I can reproduce it here. It looks like gcc is using a strange calling
convention that the i386 div.S does not understand (MI div.c seems to, though).
It's generating the following code:
0x8048541 <main+9>: mov $0x0,%eax
0x8048546 <main+14>: sub %eax,%esp
0x8048548 <main+16>: lea 0xfffffff8(%ebp),%eax
0x804854b <main+19>: sub $0x4,%esp
0x804854e <main+22>: push $0x60
0x8048550 <main+24>: push $0x300
0x8048555 <main+29>: push %eax
0x8048556 <main+30>: call 0x80483ec <div>
0x804855b <main+35>: add $0xc,%esp
At the time of the call to div():
(gdb) x/4w $esp
0xbfbffbbc: 0x0804855b 0xbfbffbe8 0x00000300 0x00000060
It looks like gcc might be pushing the address of "ddy" and expecting div()
to put the result in there.
Microsoft C 12 generates this code:
sub esp, 8
push 96 ; 00000060H
push 768 ; 00000300H
call _div
add esp, 8
mov DWORD PTR [ebp], eax
mov DWORD PTR [ebp+4], edx
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
