------- Comment #17 from ghazi at gcc dot gnu dot org 2009-12-09 00:34 ------- (In reply to comment #15) > (In reply to comment #13) > > You can try filing a bug report at Apple, but I think a better route would > > be > > to see if we can avoid linking in the system ___divdc3 from FSF GCC. > > > This may be impossible without having FSF gcc access its own ___divdc3 under > a different symbol name. The functionality of libgcc has been subsumed into > libSystem in darwin10 and the symbols from libgcc itself are supposed to be > ignored in favor of those from libSystem... > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
I don't think we should get into a cat-and-mouse game of renaming functions that *are already FSF functions* just to avoid Apple's rewritten versions. Who's to say they won't override the new name(s) in a future release with the same broken copy(ies)? The sad thing is they changed ___divdc3 and they don't even emit it from their compiler. :-/ If you want to file a bug report at Apple using the FSF generated assembly (and C testcase for reference), please proceed. I hope they fix their ___divdc3 routine. Note there may be other complex math things they've rewritten. Someone would need to audit Apple's compiler to see what else they've changed. On what to do about builtin-math-7.c testcase, my inclination is we should just XFAIL it for darwin10 since fixing darwin's ___divdc3 won't help with distributions out in the field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333