Bugzilla Bug 201596

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)