standards/175811: libstdc++ needs complex support in order use C99

[David Schultz]

On Thu, May 30, 2013, Warner Losh wrote:
> 
> On May 30, 2013, at 12:46 AM, David Schultz wrote:
> > On Fri, Feb 22, 2013, David Chisnall wrote:
> > I was wondering if you could explain a bit about what your goal is
> > here, though.  Is there some kind of certification you are trying
> > to achieve?  Why can't you just comment out the few missing
> > functions?  You've been adamant about this issue ever since
> > joining the Project, even suggesting that we commit bogus
> > implementations just for the sake of having the symbols.  I
> > completely agree with you that the lack of progress is
> > unacceptable, and I'm sorry I haven't had more time to work on
> > this stuff myself, but I also don't understand the source of your
> > urgency.
> 
> More and more projects are refusing to work around our
> gridlock. We have to report R each new release because they have
> taken out the checks for the missing symbols. It is really an
> embarrassment to the project. We've let the perfect be the enemy
> of the good. There are R scripts that run elsewhere and not on
> FreeBSD. R is the one I know most about since I've been using R
> a lot to crunch numbers for work, but there are others.
> 
> The urgency is we'd like to have this stuff done for 10, if at
> all possible. And if not done, then a lot closer to done than
> where we are today.

It looks like the R in ports just wants logl(), which isn't
surprising, and there's already code for that.  So getting that in
for 10 is achievable.

> > The reason I'm asking is that I'm pushing to get a lot of stuff
> > into the tree quickly, but realistically, in the short term we're
> > only going to get 95% of the way there.  I doubt good
> > implementations of complicated functions that nobody uses, such as
> > erfcl() and tgammal(), are going to appear overnight.  Thus, I
> > would like to know whether the last 5% is needed quickly, and if
> > so, why.
> 
> I'm all for getting everything we can into the tree that
> produces an answer that's not perfect, but close. What's the
> error that would be generated with the naive implementation of
> 
> long double tgammal(long double f) { return tgamma(f); }
> 
> But assuming that, for some reason, produces errors larger than
> difference in precision between double and long double due to
> extreme non-linearity of these functions, having only a couple
> of stragglers is a far better position to be in than we are
> today.

Whether this is acceptable depends a lot on who needs it in the
first place, which is part of why I was asking.  For many years,
the only software that cared was libstdc++, and libstdc++ only
wanted to wrap it.

Here are some of my notes on the status of things:

long double     log2l(long double);                     -- bde
long double     logl(long double);                      -- bde
long double     log1pl(long double);                    -- bde

Bruce has these written.  We can commit them with a little cleanup.

  long double     acoshl(long double);                  -- sgk
  long double     asinhl(long double);                  -- sgk
  long double     atanhl(long double);                  -- sgk
  long double     log10l(long double);                  -- bde

These are trivial given the first three. I believe Bruce and Steve
have the code for them already.

long double     expl(long double);                      -- sgk
long double     expm1l(long double);                    -- sgk

Steve has perfectly committable patches that I've already approved
(and furthermore, he doesn't need my approval anymore!)

  long double     coshl(long double);
  long double     sinhl(long double);
  long double     tanhl(long double);
  long double     erfcl(long double);
  long double     erfl(long double);

These are easy given expl() and expm1l().

long double     powl(long double, long double);

This is not so easy, but important, so we can make it a priority.

long double     lgammal(long double);
long double     tgammal(long double);

These are neither easy nor important; this gets back to my question.

float complex clogf(float complex);                     -- bde
double complex clog(double complex);                    -- bde

Bruce has code for these, which should be straightforward to turn
into something committable.

float complex cpowf(float complex, float complex);
double complex cpow(double complex, double complex);

This one is tough to do well and even tougher to test -- lots of
nasty corner cases.

long double complex cexpl(long double complex);
long double complex ccosl(long double complex);
  long double complex ccoshl(long double complex);
long double complex csinl(long double complex);
  long double complex csinhl(long double complex);
long double complex ctanl(long double complex);
  long double complex ctanhl(long double complex);
long double complex cacosl(long double complex);
  long double complex cacoshl(long double complex);
long double complex casinl(long double complex);
  long double complex casinhl(long double complex);
long double complex catanl(long double complex);
  long double complex catanhl(long double complex);
long double complex clogl(long double complex);
long double complex cpowl(long double complex, long double complex);

The long double versions of the complex math functions are trivial
once the long double versions of the corresponding real functions
are written.