Mail Archives: djgpp/2003/04/26/12:13:50
Eric Rudd wrote:
> Ben Peddell wrote:
>
>> Obviously, some sort of optimization puts the div_t structure in
>> %edx:%eax instead of 16(%ebp). It would be a good optimization if it
>> didn't break the libraries.
>
>
> Yes, indeed. So, it looks as if there is a gcc bug here. Where are the
> calling conventions documented? I couldn't find them in the gcc.ixx
> docs. I think I ought to isolate this and submit a bug report, if gcc
> is indeed at fault. I suppose a workaround would be to recompile libc,
> but then one wonders whether all the other libraries are also broken.
>
> -Eric Rudd
> rudd AT cyberoptics DOT com
>
I'm pretty sure I saw somewhere that char, short, int and long are
returned in eax. long long is returned in edx:eax. Anything longer than
that is returned in memory.
I guess that without the optimization, gcc returns the div_t structure
in memory, but with the optimization, gcc returns it in edx:eax since it
sees that it is the length of a long long.
GCC 3.2.1 (the gcc I have under DJGPP) does not optimize the div_t into
a long long when given -O3 or -fomit-frame-pointer.
In fact, -fomit-frame-pointer does nothing.
I went to www.delorie.com to get gcc 3.2.2, and had a look at your bug
report whilst I was there.
What command line did you use?
Anyway, I'm getting gcc 3.2.2.
I'll get back tomorrow when I install it.
- Raw text -