[csw-maintainers] gcc __sync_fetch_and_add revisited

[Ben Walton]

Hi All,

I bumped into a problem that others have seen previously and I _think_
I found the problem...

Certain c++ apps fail to build on sparc with the 'undefined symbol
__sync_fetch_and_add4' error.  It seems that this may be due to the
way gcc was packaged for sparc.

If we look through the headers for __sync_fetch_and_add, we find:
include/c++/4.3.3/ext/atomicity.h (and a few others)

This file defines __exchange_and_add using __sync_fetch_and_add if
_GLIBCXX_ATOMIC_BUILTINS is defined.

This value is defined as 1 in:
include/c++/4.3.3/sparc-sun-solaris2.8/bits/c++config.h
include/c++/4.3.3/sparc-sun-solaris2.8/sparcv9/bits/c++config.h

Looking in include/c++/4.3.3/sparc-sun-solaris2.8/, we have only bits/
and sparcv9/.

As sparcv9 supports the required atomic operations but sparcv8 doesn't
(according to my reading, correct me if I'm wrong), I hypothesize that
the architecture detection done during the gcc4 build picked up the
fact that it was building on a sparcv9 and set values accordingly.
Thus, even when building things with flags forcing sparcv8, gcc thinks
it can use capabilities that it can't.

Does this all sound reasonable?

If this is the case, we should likely have gcc4 rebuilt with different
flags so that it's base is v8.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302