Use of long double math builtins on powerpc-darwin is the cause of the remaining gfortran issues on this target (at least, we can't investigate much until this is fixed). An example case is simple: the following gives wrong results.
$ cat s.c int main (void) { long double x; double y; x = -0.24; y = x; __builtin_printf ("%g %g %g\n", (float) __builtin_asinl(x), (float) __builtin_asin(y), (float) (__builtin_asinl(x) - __builtin_asin(y))); } $ gcc s.c && ./a.out -0.242366 -0.242366 0.5 asin() and asinl() values are very close, but their difference is output as 0.5. Adding #include <math.h> on top of this makes it pass: $ ./bin/gcc s2.c && ./a.out -0.242366 -0.242366 -8.82009e-18 So, while this is fine for your average C code, it's a complete failure for code generated directly by a front-end, such as gfortran, which directly uses the long double math builtins. I suppose the BUILT_IN_* fndecls have to be fixed. My question is simple: are there any plans to fix? (I've just checked, and it's still there with GCC-4.4 on MacOS 10.5.2.) It's an annoying pain for us (gfortran users obviously, and gfortran maintainers because it prevents us from testing other parts of long double support on ppc-darwin). Thanks, FX -- FX Coudert http://www.homepages.ucl.ac.uk/~uccafco/