incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: config with wide has no effect on Solaris/Intel + patch
Date Mon, 09 Jul 2007 18:31:31 GMT
Michael van der Westhuizen wrote:
> Hi Martin,
> 
> On 7/7/07, Martin Sebor <sebor@roguewave.com> wrote:
> [snip]
>>
>> I recall reading somewhere that Sun C++ 5.9 supports the gcc -m64
>> option but I can't find the reference. Do you happen to have a link?
>> The x86 equivalent I was able to find in the online documentation is
>> still -xarch=amd64 (I couldn't find -m64 in the manual):
>> http://docs.sun.com/source/819-3690/Comp_Options_App.html#pgfId-999544
> 
> I picked the flags up here -
> http://developers.sun.com/sunstudio/documentation/ss12/whatsnew.html

Ah, that's the page I read! Thanks!

> 
> The xarch flags used result in compile-time warnings with C++ 5.9, so
> the -mXX options are really necessary.

Agreed. I created a separate issue for this:
https://issues.apache.org/jira/browse/STDCXX-479

> 
> It's possible to further tune the generated code using non-deprecated
> -xarch options - there are details in the links above.
> 
>> We're only just getting around to setting up the compiler but once it's
>> up and running we'll test your patch with it.
> 
> I've found quite a few issues with C++ 5.9, so we'll probably stick to
> 5.8+patches for now - at least until the obvious optimiser bugs are
> worked out.
> 
> I've logged a compile-time showstopper (a ube assertion that crops up
> in both 4.1.3 and 4.2.0) with bugs.sun.com, but I haven't logged a
> runtime problem with the numeric limits configuration test which makes
> it impossible to compile with any optimisation on sparcv8/sparcv9 (I
> haven't had time to look into the problem).

Ugh. Sounds like we have some work to do...

> 
> I'm also seeing the support/atomic* tests timing out on the i386 and
> amd64 - this is unexpected, but I haven't had time to look into this
> yet.

Check the list and Jira in case we figure out before you do
(otherwise keep us posted -- thanks!)

Martin

> 
> Some of the tests are also hitting backend corner cases - I've never
> seen the UBE take as much memory as it does now, and I've never seen
> it use a whole CPU before:
>  7723 michael   315M  312M cpu0     0    0   0:05:43  50% ube/1
> 
> Michael


Mime
View raw message