ICC is compatible with most current GCC versions (in portage) up to 4.1.x . 4.2.x series GCC breaks this compatibility and there should be some sort of warning surrounding this (icpc is rendered useless in the presence of 4.2 as the main compiler). Reproducible: Always Steps to Reproduce: Attempt to compile a simple CPP test program fails. kyron@kyron ~/_________temp $ cat test.cpp #include <string> int main () { std::string foo = "Hello, world" ; return 0; } Actual Results: kyron@kyron ~/_________temp $ icpc test.cpp -o test /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include/g++-v4/ext/atomicity.h(51): error: identifier "__sync_fetch_and_add" is undefined { return __sync_fetch_and_add(__mem, __val); } ^ /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include/g++-v4/ext/atomicity.h(55): error: identifier "__sync_fetch_and_add" is undefined { __sync_fetch_and_add(__mem, __val); } ^ compilation aborted for test.cpp (code 2) Expected Results: Hello, world I was unable to find information either on Intel's site nor GCC's site relating to this problem and/or expected time to fix of this issue.
not a gcc issue ... assign to whoever watches icc
Bug#: 194513 has a proposed workaround which is: [...snip...] The solution is to commend out the line: #define _GLIBCXX_ATOMIC_BUILTINS 1 in /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.1/include/g++-v4/x86_64-pc-linux-gnu/bits/c++config.h [...snip...] The impact of unsetting _GLIBCXX_ATOMIC_BUILTINS is seen in /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include/g++-v4/ext/atomicity.h (of course...hence the error message ;) ) From atomicity.h: #ifdef _GLIBCXX_ATOMIC_BUILTINS static inline _Atomic_word __exchange_and_add(volatile _Atomic_word* __mem, int __val) { return __sync_fetch_and_add(__mem, __val); } static inline void __atomic_add(volatile _Atomic_word* __mem, int __val) { __sync_fetch_and_add(__mem, __val); } #else _Atomic_word __attribute__ ((__unused__)) __exchange_and_add(volatile _Atomic_word*, int); void __attribute__ ((__unused__)) __atomic_add(volatile _Atomic_word*, int); #endif The following is also impacted: /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include/g++-v4/ext/concurrence.h [...snip...] #ifdef _GLIBCXX_ATOMIC_BUILTINS _S_atomic; #else _S_mutex; #endif [...snip...] So, un-setting _GLIBCXX_ATOMIC_BUILTINS is an "solution" but it remains unclear as to the performance impact.
...Ok, so obviously, there shouldn't be any output when executing `test`, that was me out of coffee and sleep ;)
Yeah, so don't use ICC.
I think it still could be a gcc regression, at least with respect to this gcc-bugzilla bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671 This for example did break my 'emerge -e system' at least with gcc-4.2.0 without -march (so defaulting to -march=i386). Didn't recheck with gcc-4.2.2 p1.0 I currently use, but I suspect the regression is still there, since I'm not sure the final fix proposed there ever went into the 4.2 release branch.
Re-opening. This issue should be at least addressed in icc's ebuild in the form of a warning message. Furthermore, the addition of ATOMIC_BUILTINS is relatively recent and warrants some caution on it's actual use. One can expect more problems to arise from this in the near future as people will do the transition to 4.2.x series. For more details, please read: http://gcc.gnu.org/ml/libstdc++/2006-07/msg00013.html
There might be a hint of another workaround (with less system-wide impact) at: http://www.intel.com/software/products/compilers/docs/clin/main_cls/mergedprojects/bldaps_cls/common/bldaps_interop_options_comm.htm By using -cxxlib (not -gcc-version 420, that obviously doesn't work). This would imply that we specify (a copy?) of the libstdc++ headers that don't include the Atomic ops. This way GCC compiled apps are optimized with these new features and ICC apps _can_ be compiled ;)
For minimal impact I'd suggest adding -DICC to icc compiles and doing this inside /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/x86_64-pc-linux-gnu/bits/c++config.h #if ! defined(ICC) #define _GLIBCXX_ATOMIC_BUILTINS 1 #endif
(In reply to comment #8) > /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.2/include/g++-v4/x86_64-pc-linux-gnu/bits/c++config.h > > #if ! defined(ICC) > #define _GLIBCXX_ATOMIC_BUILTINS 1 > #endif > I definitely vote for this workaround.
re-cc toolchain for advice on gcc. What's the future of the file c++config.h on future versions of gcc? Does the solution proposed in comment #8 seem reasonable to you?
no, such a change is not acceptable (to me). maybe you can convince upstream on such a thing, but i'm not going for it. presumably such a change would be a temporary solution ... maybe with gcc-4.2.x, such an addition is "new", but what are you going to do about gcc-4.3 ? gcc-4.4 ? googling shows that the icc guys are already dealing with this
icc-10.1.012 just made it to the tree. Could you test it? It seems that upstream put some work into it.
Unable to reproduce original test. Using gcc-4.2.2 and icc-10.1.0.12. Is this bug still valid?
Seems fixed then. Re-open if the problem persists in versions >= 10.1.012 Thanks
I've just checked it and icc-10.1.013 and gcc-4.2.3 still seem to be incompatible- I receive the same error (__sync_fetch_and_add undefined). The line: "#define _GLIBCXX_ATOMIC_BUILTINS 1" is already in the c++config.h file.
This bug is present with gcc 4.2.3 and ICC 10.1.015. The aforementioned workaround is wrong, the right one is: #ifndef __INTEL_COMPILER #define _GLIBCXX_ATOMIC_BUILTINS 1 #endif (look at http://predef.sf.net)
