I am currently evaluating several compilers to maybe speed up an existing project that does heavy number crunching. Amongst others, I also gave the compiler suite that comes with the Oracle Solaris Studio a try and I am having a few questions that I'd kindly like to ask here. Thanks for any suggestions/informations/hints in advance.

1]
Since I do not want to recompile all dependencies (amongst others Qt, boost, ...) for the project, I was trying to use the new -compat=g flag but CC spit out more errors than one would imagine. It was unable to find the appropriate pathes and all and even after setting them accordingly with the appropriate -I flag, it choked on most of what it found. What is the correct way of using the -compat=g flag and what environment variables/flags do I have to set as well? I guess gcc 4.6 (which is the version I have installed) is not yet supported and won't really work?

2]
Am I assuming correctly that if I use -compat=g or use stlport4, I cannot make use of the optimized math library that comes with the compiler suite as a replacement for the regular libm?

3]
The project I am trying to compile, makes heavy use of the STL and boost. The standard libCstd does not support every feature - which also goes for some of the project's dependencies as well. Is the stlport4 or the native g++ stl the only way to solve this?

4]
With every compile, I get "CC: Warning: failed to detect system linker version, falling back to custom linker usage". I was unable to figure out what the actual repercussions are and how I could eventually fix this. If someone could please shed any light on this, it would be greatly appreciated.

5]
I have a small test program which basically is a loop that iterates UINT32_MAX times and does some calculation. I use OpenMP's parallel for without any hint to scheduling, number of threads or such. All compilers (g++, icc, path64) I tried, correctly put out 8 threads to handle the load. Except for the version compiled with solaris studio compiler. It only launched two threads and came in last. After manually forcing it to 8 threads (OMP_NUM_THREADS=8), it worked like a charm and even took the lead. Again, it is a simple and stupid test. But I wonder what I am missing because it should not be the user's job to set the right number of thread for his machine.

By the way, all tests have been performed on a x86_64 Linux system (Gentoo) w/ gcc 4.6.2 and Studio 12.3 (tar).

Sorry, Gentoo is not a supported system (though something might still work).

And gcc 4.6.2 is definitely not supported for -compat=g. Actually anything higher than 4.3 is very likely not to work.
Its headers contain alot of gcc'isms and Studio 12.3 is not able to handle it all.
I do not believe it is possible to workaround these problems.

We gradually move towards being able to work with modern gcc's, but our main target is gcc version installed by default on supported Solarises.
And Solaris is not that quick in adopting latest gcc versions either.

Am I assuming correctly that if I use -compat=g or use stlport4, I cannot make use of the optimized math library that comes with the compiler suite as a replacement for the regular libm

Math stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.

heavy use of the STL and boost. The standard libCstd does not support every feature - which also goes for some of the project's dependencies as well. Is the stlport4 or the native g++ stl the only way to solve this?

We claim support for Boost with -compat=5 -library=stlport4 mode only.

With every compile, I get "CC: Warning: failed to detect system linker version, falling back to custom linker usage".

Old Linux linkers (GNU ld, versions predating 2.20) are not able to properly handle C++ objects generated by Studio.
We ship slightly modified GNU ld which has these problems fixed, for C++ to work on RedHat5/OracleLinux5.
However that custom linker is an old one (version 2.17.90), so it wont work with system libraries on modern Linuxes.
On RH6/OL6 we were able to force system linker (2.20) to work properly.
Hence CC tries to detect system linker version and apply a workaround.
It seems that your system linker has --version output that CC cant match, so it runs old linker shipped with Studio.
Its not going to do anything good :(

I have a small test program which basically is a loop that iterates UINT32_MAX times and does some calculation. I use OpenMP's parallel for without any hint to scheduling, number of threads or such. All compilers (g++, icc, path64) I tried, correctly put out 8 threads to handle the load. Except for the version compiled with solaris studio compiler. It only launched two threads and came in last. After manually forcing it to 8 threads (OMP_NUM_THREADS=8), it worked like a charm and even took the lead. Again, it is a simple and stupid test. But I wonder what I am missing because it should not be the user's job to set the right number of thread for his machine.

Wonder what kind of hardware do you have?
Starting number of threads is a "static" decision performed by OpenMP runtime at the start of the paralllel region and is implementation-defined (thus any choice is ok wrt OpenMP standard).
I dont remember whats our heuristics for this decision is right away, but it should be something proportional to the number of CPUs.
It is nearly impossible to make an efficient decision for every program/hardware combo.
Either our heuristics happens to not match your test program, or the runtime fails to detect the number of CPUs on your system.

I cant see non-cumbersome workarounds currently. Will get back to it later.

For now, I've replaced the bundled "ld" with a symlink to the system one. :)

By the way, doing a strace revealed nothing interesting. 27796 was the pid of the system ld which simply processed the version option. But still, you can see the version string which maybe not quite to the liking of suncc:

A hack (and it's just that) is to edit bfd/configure, changing PKGVERSION="(GNU binutils) " to "*PKGVERSION="version "*. That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CC as a valid version string. Rebulld and install that modified version of the binutils package.