Skip to Main Content
Forums

DevOps, CI/CD and Automation

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

g++ compatibility / STL / boost and Qt / OpenMP

919808Feb 24 2012 — edited Nov 15 2012
Hello everyone.

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).

Thanks again and have a nice weekend,
matthias.

Comments

Fedor-Oracle
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.

regards,
__Fedor.

Edited by: SFV on Feb 24, 2012 4:22 PM
919808
Sorry, Gentoo is not a supported system (though something might still work).
I know. That goes for most software, actually... and one gets used to it, if you do not use one of the major distros. But on the other hand, it rarely causes any problems that cannot be solved.
And gcc 4.6.2 is definitely not supported for -compat=g. [...]
Ah, okay. Thanks for that information. That explains a lot and I will stay clear of it in the future until I read otherwise in the release logs. :)
Math stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.
At least that door for a good speed up is still open. Nice to hear.
We claim support for Boost with -compat=5 -library=stlport4 mode only.
-library=stlport4 implies -compat=5, if I am not mistaken? Or -compat=5 is the default anyways. I remember having read something about it.
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 :(
Is there any way I can workaround that or force the compiler to use my linker nevertheless?
Wonder what kind of hardware do you have?
Core i7 860 (4 real cores + 4 HT).
Either our heuristics happens to not match your test program, or the runtime fails to detect the number of CPUs on your system.
I would guess it is most likely the latter. Is there any way I can force debug information about this?

Thanks for your swift answer by the way, it is very much appreciated.

So long
matthias
Fedor-Oracle
-library=stlport4 implies -compat=5,
Yes, that was somewhat ambiguous.
We claim the support for Boost with -library=stlport4 only.

You might get a reasonable set of Boost libraries working fine with -compat=g. But then again, -compat=g does not work for you..
Is there any way I can workaround that or force the compiler to use my linker nevertheless?
I cant see non-cumbersome workarounds currently. Will get back to it later.

regards,
__Fedor.
919808
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:

<... setregid resumed> ) = 27796
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=27796, si_status=0, si_utime=0, si_stime=0} (Child exited) ---
[ Process PID=27791 runs in 32 bit mode. ]
open("/tmp/gnuld_version.1330099288.27791.03", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=266, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff718f000
read(3, "GNU ld (GNU Binutils) 2.22\nCopyr"..., 4096) = 266
read(3, "", 4096) = 0
write(2, "CC: Warning: ", 13CC: Warning: ) = 13
write(2, "failed to detect system linker v"..., 76failed to detect system linker version, falling back to custom linker usage
) = 76

Hope that helps.

Thanks again for your help.

So long,
matthias
974389
khaos wrote:
write(2, "failed to detect system linker v"..., 76failed to detect system linker version, falling back to custom linker usage
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.

Edited by: user1398506 on Nov 15, 2012 1:03 AM
Fedor-Oracle
That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CC
Indeed, CC matches version text with "GNU ld version" string. This is what linker on our supported platforms reports.

A good news is that we might drop shipping modified linker (and thus there will be no need for linker detection) in a future release.

regards,
__Fedor.
Steve.Clamage-Oracle
[posted by mistake]
1 - 7
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Dec 13 2012
Added on Feb 24 2012
#developer-studio, #developer-studio-ide-debugging-and-analysis-tools, #linux
7 comments
4,017 views