Re: current mainline, port status

[Benjamin Kosnik <benjamin dot kosnik at gmail dot com>]

> >FAIL: 26_numerics/complex/13450.cc (test for excess errors)
> >FAIL: 26_numerics/complex/complex_value.cc (test for excess errors)
> >FAIL: 26_numerics/complex/pow.cc (test for excess errors)
> >
> >all fail with various forms of (this linker error):
> >
> >...libstdc++-v3/include/complex:593: undefined reference to `carg'
> >[and cargf, cexpf, cexp, cabsl]
> >
> >How are other ports looking these days?
> >  
> >
> I think the single most importante open issue is the above, which also
> affects hpux, and Darwin, for instance, but I haven't really studied it
> in detail: I'm afraid, for 4.0 at least, we can only "fix" it by a 
> combination
> of configury bits and testsuite tweaks.

Yo dudes.

I seem to remember this dimly: Gaby asked for help with some of the
complex bits, where __builtin_carg wasn't available or couldn't be used,
and so a reference to carg is used instead.

I can't find the reference right now on the list. Gaby?

>From a brief look at std_complex.h, I would think that one thing we
could do is a generic macro like _GLIBCXX_COMPLEX_BUILTINS, where we
flip that on at configure time if all the builtin functions are present,
and then guard the specializations that use the builtins in
std_complex.h with this. 

Without the macro, code would just use the primary template (which uses
no builtins).

-benjamin