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

[Pedro Giffuni]

On 30.05.2013 01:46, David Schultz wrote:
> On Fri, Feb 22, 2013, David Chisnall wrote:
>> On 4 Feb 2013, at 03:52, Stephen Montgomery-Smith <stephen at missouri.edu> wrote:
>>
>>> We do really seem to have a lot of working code right now.  And the main
>>> barrier to commitment seems to be style issues.
>>>
>>> For example, I have code at http://people.freebsd.org/~stephen/ for the
>>> complex arctrig functions.  And Bruce has clog available.  And
>>> presumably he has logl and atanl also available.
>>>
>>> The last I heard about my code is Bruce asking for some style changes.
>>> However I really don't think I will have time to work on it until at
>>> least the summer.  And to be honest, style just isn't my thing.
>>>
>>> I propose (a) that someone else takes over my code (and maybe Bruce's
>>> code) and make the style changes, or (b) that we get a little less fussy
>>> about getting it all just so right and start committing stuff.
>>>
>>> Let me add that the code we have is already far superior than anything
>>> in Linux or NetBSD, who clearly didn't worry about huge numerical errors
>>> in many edge cases.  Come on guys, let's start strutting our stuff.
>>>
>>> Let's commit what we have, even if it isn't perfect.
>> Yes, please can this happen?  We are currently on 31 test
>> failures in the libc++ test suite on -HEAD, of which at least 18
>> are due to linker failures trying to find missing libm
>> functions.  We are very close to having a complete C++11
>> implementation, yet we are held up by the lack of C99 support,
>> and we are held up there by style nits?
>>
>> On behalf of core, please can we commit the existing code and
>> worry about the style later? Given the expertise required to
>> work on the libm functions, most of the people who are able to
>> hack on the code have already read it and so concerns about
>> consistency readability are somewhat misplaced.
> I didn't see this thread until now, but coincidentally, I just
> wrote tests and manpages for and committed Stephen's
> implementations of most of the missing double/float complex
> functions. I don't know the status of clog() or cpow(), but
> murray@ has a patch to port the NetBSD versions, which I'm also
> willing to commit given the unacceptable delays in producing
> something better.

Thank you !!

> 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.

What I am finding rather disappointing is that our libstdc++
lacks so many features wrt to what is expected from
developers used to linux.

I think it's reasonable to think that libc++ will require the same
features as modern libstdc++ to support a quality port.

In addition to R, the current situation also has undesirable
effects in boost, where we don't support long double
(nevermind the bogus patch on our ports tree).

if we if we can just get our local libstdc++ to use C99 that
would be an advance. The target at this time would be resolving
standards/175811 and it would also be interesting to see what
the upstream gcc/libstdc++ requires.

> 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 may be wrong but with long double support people that
need erfcl() and tgamma() can get them from boost.
The problem is therefore not implementing everything but
getting enough to turn on the features supported by
libstdc++ and boost.

Pedro.