Michael van der Westhuizen wrote:
Hi Martin,
On 7/7/07, Martin Sebor <[EMAIL PROTECTED]> 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
