STDCXX "fork"

["C. Bergström"-3]

Hi all

PathScale has been maintaining our internal branch of STDCXX for a while
now and recently it's gone open source (along with a few other things[1])

Having it hosted at Apache seems to have created some barriers we're
hoping to resolve.

1) "better" cmake build system (Actually this has nothing to do with
Apache or the current build system.)
2) Faster code review, QA and easier contribution process (Only the last
part is slowed down by Apache)
3) Actively maintained (To start just bug fixes, better support for
Win/ARM/Solaris and performance improvements[2].  If we get enough
interest we'll start on C++0x)

Note: The cmake based build system isn't in the tree now and should
merge mid/late next week.

If you're interested
https://github.com/pathscale/stdcxx/

If you have outstanding patches please clone and send a pull request.  
We're going to work hard to get all the backlog of stuff reviewed and
integrated.

./C

@CTOPathScale

[1] http://www.pathscale.com/ekopath4-open-source-announcement
[2] There's been a number of reported issues where just swapping out the
STL between GNU and STDCXX resolves performance issues

[Wojciech Meyer-3]

> Hi all

Hi,

> 1) "better" cmake build system (Actually this has nothing to do with
> Apache or the current build system.)
> 2) Faster code review, QA and easier contribution process (Only the last
> part is slowed down by Apache)
> 3) Actively maintained (To start just bug fixes, better support for
> Win/ARM/Solaris and performance improvements[2].  If we get enough
> interest we'll start on C++0x)

We have some armcc porting patches against 5.2.1 (or trunk), would you
be able to try to include them in your "big merge"? They are basically
build system amendments to cross compile stdcxx with our compiler and
make it work with our run time. Obviously if the build system is going
to change, I would need to spend some time porting them to cmake (hopefully
it will be straight forward), so let me know WDYT.

> Note: The cmake based build system isn't in the tree now and should
> merge mid/late next week.

Great.

> If you're interested
> https://github.com/pathscale/stdcxx/

Already cloned.

> If you have outstanding patches please clone and send a pull request.
> We're going to work hard to get all the backlog of stuff reviewed and
> integrated.

Will do. Thanks!

> ./C

Wojciech

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

["C. Bergström"-3]

  On 06/17/11 09:54 PM, Wojciech Meyer wrote:

>> Hi all
> Hi,
>
>> 1) "better" cmake build system (Actually this has nothing to do with
>> Apache or the current build system.)
>> 2) Faster code review, QA and easier contribution process (Only the last
>> part is slowed down by Apache)
>> 3) Actively maintained (To start just bug fixes, better support for
>> Win/ARM/Solaris and performance improvements[2].  If we get enough
>> interest we'll start on C++0x)
> We have some armcc porting patches against 5.2.1 (or trunk), would you
> be able to try to include them in your "big merge"? They are basically
> build system amendments to cross compile stdcxx with our compiler and
> make it work with our run time. Obviously if the build system is going
> to change, I would need to spend some time porting them to cmake (hopefully
> it will be straight forward), so let me know WDYT.

Anything not build related please send me a pull request on.  We have a
cross compile build system for our compiler, but I'm not sure how easy
it will be to pull that out just for STDCXX.  When the engineer who owns
this code is back from holiday we'll get it sorted out.

I hope we can also take a look at the Solaris and Windows patches :)

./C

[Stefan Teleman-2]

On 2011/6/17 "C. Bergström" <cbergstrom@...> wrote:

> I hope we can also take a look at the Solaris and Windows patches :)

You can svn co all the stdcxx Solaris patches from here:

http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/

The patches can be found in the Solaris/diffs/ directory.
The shell script to apply the patches is Solaris/apply_patches.sh
The patches are based on the stdcxx 4.2.1 release.

Anonymous svn should work. If it doesn't work for you please let me
know, it only means something is messed up.

Some of the patches are very Solaris and/or Studio C++ specific (the
sunpro.config patches, the GNUmakefile* patches and the patches for
the Standard C Library forwarding header files (cstdio, cstdlib,
cstring, clocale, etc ...).

I will start submitting patches here (at Apache) soon.

--Stefan

--
Stefan Teleman
KDE e.V.
stefan.teleman@...

["C. Bergström"-3]

  On 06/26/11 11:23 AM, Stefan Teleman wrote:

> On 2011/6/17 "C. Bergström"<cbergstrom@...>  wrote:
>
>> I hope we can also take a look at the Solaris and Windows patches :)
> You can svn co all the stdcxx Solaris patches from here:
>
> http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/
>
> The patches can be found in the Solaris/diffs/ directory.
> The shell script to apply the patches is Solaris/apply_patches.sh
> The patches are based on the stdcxx 4.2.1 release.
>
> Anonymous svn should work. If it doesn't work for you please let me
> know, it only means something is messed up.
>
> Some of the patches are very Solaris and/or Studio C++ specific (the
> sunpro.config patches, the GNUmakefile* patches and the patches for
> the Standard C Library forwarding header files (cstdio, cstdlib,
> cstring, clocale, etc ...).
>
> I will start submitting patches here (at Apache) soon.

The last time we checked the patches they caused some boost regressions
so please make sure to run the boost test suite.

Our compiler runs on Solaris and which patches are platform, but not
compiler specific?

Thanks

[Stefan Teleman-2]

2011/6/26 "C. Bergström" <cbergstrom@...>:

> The last time we checked the patches they caused some boost regressions so please make sure to run the boost test suite.

We don't run the Boost tests to validate the 2003 C++ Standard. We run
the 2003 C++ Standard validation tests. If strict conformance to the
2003 C++ Standard causes problems with Boost, then that's a Boost
problem and not a stdcxx problem.

There were indeed numerous deviations from the 2003 C++ Standard in
the original stdcxx implementation.

--Stefan

--
Stefan Teleman
KDE e.V.
stefan.teleman@...

["C. Bergström"-3]

  On 06/26/11 11:55 AM, Stefan Teleman wrote:

> 2011/6/26 "C. Bergström"<cbergstrom@...>:
>
>> The last time we checked the patches they caused some boost regressions so please make sure to run the boost test suite.
> We don't run the Boost tests to validate the 2003 C++ Standard. We run
> the 2003 C++ Standard validation tests. If strict conformance to the
> 2003 C++ Standard causes problems with Boost, then that's a Boost
> problem and not a stdcxx problem.
>
> There were indeed numerous deviations from the 2003 C++ Standard in
> the original stdcxx implementation.

Do any of your patches fix these and if so which one(s)?  Do you have
reduced test cases or which test suite?

[Stefan Teleman-2]

On 2011/6/26 "C. Bergström" <cbergstrom@...> wrote:

> Do any of your patches fix these and if so which one(s)?  Do you have
> reduced test cases or which test suite?

Yes, the vast majority of the patches are about C++2003 conformance.

C++VS - Perennial C++ Validation Suite (CPPVS)

http://www.peren.com/pages/cppvs_set.htm

Yes we do have reduced test cases for the violations, but we cannot
publish them because Perennial CPPVS must be licensed.

--Stefan

--
Stefan Teleman
KDE e.V.
stefan.teleman@...

["C. Bergström"-3]

  On 06/26/11 10:31 PM, Stefan Teleman wrote:

> On 2011/6/26 "C. Bergström"<cbergstrom@...>  wrote:
>
>> Do any of your patches fix these and if so which one(s)?  Do you have
>> reduced test cases or which test suite?
> Yes, the vast majority of the patches are about C++2003 conformance.
>
> C++VS - Perennial C++ Validation Suite (CPPVS)
>
> http://www.peren.com/pages/cppvs_set.htm
>
> Yes we do have reduced test cases for the violations, but we cannot
> publish them because Perennial CPPVS must be licensed.

PathScale has a Perennial license and feel free to privately email which
issues the patches specifically fix.

Thanks

[Stefan Teleman-2]

2011/6/26 "C. Bergström" <cbergstrom@...>:

> PathScale has a Perennial license and feel free to privately email which
> issues the patches specifically fix.

Great, then PathScale can run the Perennial C++ validation tests on
PathScale's recently published stdcxx fork.

I looked at the github code published by PathScale and it is obvious
to me that it has not been validated against *any* C++2003 validation
test harness.

--Stefan

--
Stefan Teleman
KDE e.V.
stefan.teleman@...

["C. Bergström"-3]

  On 06/27/11 01:17 AM, Stefan Teleman wrote:
> 2011/6/26 "C. Bergström"<cbergstrom@...>:
>
>> PathScale has a Perennial license and feel free to privately email which
>> issues the patches specifically fix.
Your false statements are annoying and unnecessary.

Please don't avoid the question as I'm trying to help review your
changes.  Either publicly or privately email which patch fixes which
Perennial test.  (If in fact you've ran them at all)

[Stefan Teleman-2]

2011/6/27 "C. Bergström" <cbergstrom@...>:

> Your false statements are annoying and unnecessary.

I deeply regret that I am annoying you.

> Please don't avoid the question as I'm trying to help review your changes.
>  Either publicly or privately email which patch fixes which Perennial test.
>  (If in fact you've ran them at all)

Quite frankly, I really don't need your help in reviewing my patches.
They've already been reviewed.

My current job description does not require me to help you run the
Perennial validation tests, or to provide you with any information
about the Perennial test results. As a matter of fact, I don't even
have to provide you with patches at all. I am doing this as a
courtesy: you stated that you wanted to look at the Solaris patches.

You work for a compiler writer, and you stated you have a Perennial
license. You should, therefore, be able to run the Perennial tests
yourself.

I stand by my previous statement: you have not validated the github
fork of stdcxx against any validation test harness. Had you done so,
several tests would/should have failed. Had you corrected the stdcxx
code causing these failures (which you have not, I have verified that
the violations are still there), several tests from the apache stdcxx
test harness would have failed, and these tests would have required
patches too. I do not see the necessary code changes, and I can tell
all this by looking at the PathScale stdcxx fork code.

--Stefan

--
Stefan Teleman
KDE e.V.
stefan.teleman@...