1) When a function returns a double, GCC returns it differently according to the CPU option.
- for 68000 and ColdFire, doubles are returned into d0/d1.
- for m68020-60, doubles are returned into fp0.
Also, assembler routines must be aware of that difference among CPU options, and return the values into the right register.
I think nobody is writing math code which returns float but it's aimed for 68000. But that's not an excuse, of course.
Some m68k targets don't use this default behavior, and return the doubles into d0/d1 in any case. GCC 2.95.3 and GCC 4.x for MiNT use the default behavior (different registers), I really wonder if this is a good thing.
Hmm, except immediate break of some still developed FPU software (we could print a warning message while rpm update process) I see no reason why to keep this bad habit of d0/fp0. So you've got one vote from me :)
As a result, PML for -m68020-60 has always been compiled using the 68000 implementation, which can be wrong because of 1). Fortunately, that
Damn it! I must check this but I fear you're right :-/ Yeah, this is real bug, no doubt.
- GCC provides math-68881.h, it contains inline implementations of the math functions using the equivalent FPU instructions. That file should be automatically included by math.h, but I'm pretty sure it is not the case right now. To be investigated.
I don't understand, what's the difference between "native" FPU version of pml (or any other math lib) and this inline implementations?
As you see, big mess.
I really think we should drop PML and fdlibm and use another libm from an actively maintained project (Newlib, BSD...), since there is nothing specific to the OS.
I agree, in fact, it's not that difficult but it requires at least a few days, any volunteers? :)