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
|