Bug 28671 - [4.2 regression] undefined reference to `__sync_fetch_and_add_4'

What options are being used to compile the software with?
if -march=i386, then this is not a bug with the compiler.

-O2 -march=i586 -mcpu=i686 -fomit-frame-pointer

First, a general remark: this kind of error must never happen, irrespective of
the options used to build user code and/or GCC.

Then, it looks like _GLIBCXX_ATOMIC_BUILTINS is defined for that installation
of GCC. In turn, this is not supposed to happen for ?86, *any* ?. Either
something is wrong in the installation (something was forced overriding the
configure choices) or there are glitches in the recent changes from Benjamin.
Note, if the library is really at fault in that way, any trivial program using
string will not link, no complex applications are needed to reproduce.

One additional remark: if the entire software package is really built with
-march=i586, then, in any case, the __sync_fetch_and_add call at line 47 of
atomicity.h is expanded in line and the link problem cannot occur as reported.
About this, I agree with Andrew. But really, I would suggest reinstalling GCC
in a totally clean way and trying again.

Benjamin, in case this problem is confirmed (and some strange details of the PR
are sorted out), can you please double check that we are not incurring in the
issue I was fearing here:

  http://gcc.gnu.org/ml/libstdc++/2006-07/msg00088.html

???

Thanks a lot!

Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
the compiler, strigi was built without any -march= tags (making the default
i386, I guess).

Using -march=i586 in strigi makes the problem go away, and the problem is 100%
reproducable even when compiling a simple test app without -march=i586.

Maybe it's just the combination of compiling the compiler (and libstdc++) with
-march=i586 and then compiling an app without it

Can you give your exact commands use to build GCC?

(In reply to comment #6)
> Ok, misunderstanding about the compiler flags -- -march=i586 was used to build
> the compiler, strigi was built without any -march= tags (making the default
> i386, I guess).
> 
> Using -march=i586 in strigi makes the problem go away, and the problem is 100%
> reproducable even when compiling a simple test app without -march=i586.

Ok, that makes sense and then, yes, it's the issue I was fearing in that
message. The problem seems to be that the autoconf test
GLIBCXX_ENABLE_ATOMIC_BUILTINS is *always* run (irrespective of the details of
configure.host), thus _GLIBCXX_ATOMIC_BUILTINS defined for your GCC build
flags, and then you have always to use -march=i486 (or higher) when compiling
your code. Annoying to say the least. We don't want that. Thanks for your
report.

i have the same problem on my machine, using the latest snapshot.

i'm not sure, if the following information is helpful, but gcc -v gives me:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/gcc-4.2.0_alpha20060812/work/gcc-4.2-20060812/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.2.0-alpha20060812
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20060812/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.0-alpha20060812
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.0-alpha20060812/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.0-alpha20060812/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20060812/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix
--enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.2.0-alpha20060812  (experimental) (Gentoo 4.2.0_alpha20060812)

the cflags and cxxflags to build gcc were: -march=pentium-m -pipe -O2

would be great, to have this resolved, soon ...

Don't worry, the problem will be *certainly* resolved in time for the release:
the issue is clear, we know in detail what's going wrong and how to fix it.
Benjamin will.

Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
for __sync_fetch_and_add support) that the compiler should provide it as a
preprocessor symbol.

If you move cpu/generic/atomicity_{builtins,mutex}/atomicity.h to
include/bits/atomicity_{builtins,mutex}.h, cpu/generic/atomicity.h can be
simply:


#include <bits/atomicity.h>

#ifdef __ATOMIC_BUILTINS__
#include <bits/atomicity_builtins.h>
#else
#include <bits/atomicity_mutex.h>
#endif

Similarly, in all the cpu/*/atomicity.h files you would have

#include <bits/atomicity.h>

#ifdef __ATOMIC_BUILTINS__
#include <bits/atomicity_builtins.h>

#else /* !__ATOMIC_BUILTINS__ */

_GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx)
...
_GLIBCXX_END_NAMESPACE

#endif /* !__ATOMIC_BUILTINS__ */


Does this make sense?  If so, I'm happy to write a patch to define the symbol.

(In reply to comment #11)
> Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
> for __sync_fetch_and_add support) that the compiler should provide it as a
> preprocessor symbol.

Yes, and a patch for that would be definitely welcome, I was going to work on
it, per:

  http://gcc.gnu.org/ml/libstdc++/2006-07/msg00103.html
  http://gcc.gnu.org/ml/libstdc++/2006-07/msg00106.html

but, as I said, you are very welcome. That symbol would be immediately useful
for header code not calling into the library (-> no compatibility problems,
e.g., tr1::shared_ptr would be immediately changed to use it).

However, for the atomicity *headers* themselves, we don't want to exploit fine
grained info about the sub-target on x86, Sparc, for example, because we want
user code independent from the atomicity model, without going for mutexes
everywhere (old story about distros: don't want to prepare separate distros for
i386 and i486): in such cases the atomicity routines must remain out-of-line in
the compiled library. However, that reasoning means that, as I suggested
already, in those cases you could exploit anyway the dynamical preprocessor
builtin when building the routines in the out-of-line library (that would
enable exploiting the builtins on i486+ for example). Much more sophisticated
approaches, optimal in every case, are possible only by way of multilibs, AFAIK
(also discussed a lot in the past).

Agreed?

Just a note. 

The current behavior is as intended, although perhaps not documented. I'll be
fixing that later today.

Here's a message from last month detailing in advance this exact bug report:
http://gcc.gnu.org/ml/libstdc++/2006-07/msg00084.html

What this means is that people building gcc with -march flags then need to
consistently pass those same flags around when using the compiler. Yes, this is
a pain. We're working on a better way to do this.

The real issue is: "code independent from the atomicity model." The only way to
have this is to not inline the atomic helper functions in atomicity.h. I am
willing to revert that part of my July atomics config change. 

Although I would prefer not to. 

-benjamin

(In reply to comment #13)

> The real issue is: "code independent from the atomicity model." The only way
> to have this is to not inline the atomic helper functions in atomicity.h. I am
> willing to revert that part of my July atomics config change. 
> 
> Although I would prefer not to. 

Unfortunately, for targets like ?386 and Sparc I'm afraid it's the only option,
at the moment. For ia64, powerpc, s390, etc, etc, when the atomic functions are
always available, irrespective of the subtarget, that's fine of course. I thinh
we can leave with that, frankly: for strings we are moving away from reference
counting anyway; when running single-thread now we don't call the atomic
functions; finally, for things like shared_ptr we can have the fine-grained
preprocessor builtin and everything is nice.

(In reply to comment #14)

Sorry about my crazy english today, I'm concentrated on something else...

> Unfortunately, for targets like ?386 and Sparc I'm afraid it's the only 
> option, at the moment. For ia64, powerpc, s390, etc, etc, when the atomic 
> functions are always available, irrespective of the subtarget, that's fine
> of course.

Here of course I meant: "everything is fine, of course".

> I think we can leave with that, frankly:

... and here I meant: "live with that".

Mine.

Subject: Bug 28671

Author: bkoz
Date: Thu Aug 31 10:45:59 2006
New Revision: 116601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116601
Log:
2006-08-31  Benjamin Kosnik  <bkoz@redhat.com>

    PR libstdc++/28671
    * include/bits/atomicity.h (__exchange_and_add): Declare only.
    (__atomic_add): Same.
    * config/cpu/generic/atomicity_builtins/atomicity.h: Remove comment.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h
    trunk/libstdc++-v3/include/bits/atomicity.h

Fixed.

Subject: Bug 28671

Author: bkoz
Date: Thu Aug 31 22:20:09 2006
New Revision: 116608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116608
Log:
2006-08-31  Benjamin Kosnik  <bkoz@redhat.com>

    PR libstdc++/28671 continued
    * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Don't use
    CXXFLAGS when checking for atomic builtins.
    * configure: Regenerate.
    * include/bits/atomicity.h: Revert.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/acinclude.m4
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/include/bits/atomicity.h