long double trouble

push

#include <math.h>

int main() {
  long double r;
  long a = 4, b = 6;
  r = atan2l(a, b);
  printf("%.20Lf\n", r);
  r = atan2(4, 6);
  printf("%.20Lf\n", r);
  r = atan2l(4, 6);
  printf("%.20Lf\n", r);
}

Above code compiled with cc -lm results on NetBSD with:
0.58800260354756750392
0.58800260354756750392
0.58800260354756755124

It is not expected behaviour.
linux gives:

0.58800260354756755124
0.58800260354756750392
0.58800260354756755124

which should be normal.

Is there any siwtch to avoid NetBSD loss of precision?

Machine is Lenovo x260 with i5.

push

clang gives:
0.58800260354756750392
0.58800260354756750392
0.58800260354756750392
on NetBSD.
on linux gcc and clang result in the same output.

long double is sometime somehow promoted to double on NetBSD.

rvp

push The underlying reason for all this is that a lot of the long double math functions are stubs implemented using only double precision. Only recently have native long double trig. functions been brought in from
FreeBSD. These are in -HEAD, but, not yet in 10.x or 9.x. You can ask for pull-ups if you want.

The variance in results--it should all look like the Clang output--you see is because of GCC's optimization. Pass the values on the cmd. line and GCC won't be able to optimize the code and you'll see the same output as produced by Clang:

#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
  long double r;
  if (argc != 3)
    return 1;
  long a = atol(argv[1]), b = atol(argv[2]);
  r = atan2l(a, b);
  printf("%.20Lf\n", r);
  r = atan2(a, b);
  printf("%.20Lf\n", r);
  r = atan2l(a, b);
  printf("%.20Lf\n", r);
  return 0;
}

$ cc -o lf lf.c -lm
$ ./lf 4 6
0.58800260354756750392
0.58800260354756750392
0.58800260354756750392
$

push

Thanks,

to add a little bit more

#include <math.h>

int main() {
  long double r, fa = 4, fb = 6;
  long a = 4, b = 6;
  int aa = 4, bb = 6;
  r = atan2l(fa, fb);
  printf("%.20Lf\n", r);
  r = atan2l(aa, bb);
  printf("%.20Lf\n", r);
  r = atan2l(a, b);
  printf("%.20Lf\n", r);
  r = atan2(4, 6);
  printf("%.20Lf\n", r);
  r = atan2l(4, 6);
  printf("%.20Lf\n", r);
  r = atan2l(4LL, 6LL);
  printf("%.20Lf\n", r);
  r = atan2l(4., 6.);
  printf("%.20Lf\n", r);
}

produces
0.58800260354756750392
0.58800260354756750392
0.58800260354756750392
0.58800260354756750392
0.58800260354756755124
0.58800260354756755124
0.58800260354756755124
with gcc on NetBSD.
clang always prints the same.
Funny thing is when arguments are passed as literals,
no precission loss. For variables, precision is degraded
for any variabe type, even for long double.

rvp

push That's just GCC optimization. Look at the assembly output (gcc -S) to see what's happening.

Only the first 4 calls will go into the math library. For the remaining 3, the arguments are constants, so GCC won't make calls to libm at all. It'll convert those numbers to long double constants and do the atan2 division on its own.

push

I've spent some time to catch these features in my program.
If it is hard to implement long double math libs,
maybe some kind of warnings could be affordable
if unsupported/unfinished functions are used.
Silent approach is a little bit scary

rvp

push All that the C99 standard requires is that long double have at least as much precision as a double float type. Which is why NetBSD implementing atan2l() in terms of atan2() is OK. If you want to be sure that both the compiler and the C library have different types for long double vs. double on the running arch., you'll have to test for it.

nia

Long double's extremely unstandardized. There's plenty of CPU architectures where it doesn't even make sense.

push

True, and NetBSD coners many platforms.
Still, it is very vague when function works one way with variable,
and another way with literals. Using literals trying to detect what's going on.
I would say it is more fair how clang works, having always swiching to double.

rvp

push I would say it is more fair how clang works, having always swiching to double.

Turn optimizations on in clang and you might see a difference in output there too. (What surprised me in all this is GCC "optimizing" the code without any -O or with -O0.)

Try again with -O2 and/or -fno-builtins and see how the output changes.

push

No problem, there are alternatives, but it did catch me. Thanks again.