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/
