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

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

Summary:	[4.2 regression] undefined reference to `__sync_fetch_and_add_4'

Status: RESOLVED FIXED   Product: gcc Classification: Unclassified Component: libstdc++ Version: 4.2.0 Description bero 2006-08-09 22:40:02 UTC This happens when trying to compile strigi 0.3.2 (http://www.vandenoever.info/software/strigi/) with gcc trunk from today results in Linking CXX executable dummyindexer CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add': /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add': /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/stl_vector.h:120: undefined reference to `__sync_fetch_and_add_4' CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add': /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' CMakeFiles/dummyindexer.dir/indexer.o:/usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: more undefined references to `__sync_fetch_and_add_4' follow collect2: ld returned 1 exit status Comment 1 Andrew Pinski 2006-08-09 22:51:23 UTC What options are being used to compile the software with? if -march=i386, then this is not a bug with the compiler. Comment 2 bero 2006-08-09 22:54:01 UTC -O2 -march=i586 -mcpu=i686 -fomit-frame-pointer Comment 3 Paolo Carlini 2006-08-09 23:08:24 UTC 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. Comment 4 Paolo Carlini 2006-08-09 23:30:54 UTC 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. Comment 5 Paolo Carlini 2006-08-09 23:48:31 UTC 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! Comment 6 bero 2006-08-09 23:55:12 UTC 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 Comment 7 Andrew Pinski 2006-08-09 23:58:20 UTC Can you give your exact commands use to build GCC? Comment 8 Paolo Carlini 2006-08-10 00:05:58 UTC (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. Comment 9 tim blechmann 2006-08-17 09:43:13 UTC 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 ... Comment 10 Paolo Carlini 2006-08-17 18:40:52 UTC 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. Comment 11 Paolo Bonzini 2006-08-25 07:09:59 UTC 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. Comment 12 Paolo Carlini 2006-08-25 08:08:28 UTC (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? Comment 13 Benjamin Kosnik 2006-08-28 09:49:35 UTC 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 Comment 14 Paolo Carlini 2006-08-28 09:58:08 UTC (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. Comment 15 Paolo Carlini 2006-08-28 10:02:39 UTC (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". Comment 16 Benjamin Kosnik 2006-08-31 09:08:05 UTC Mine. Comment 17 Benjamin Kosnik 2006-08-31 10:46:08 UTC 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 Comment 18 Andrew Pinski 2006-08-31 16:59:56 UTC Fixed. Comment 19 Benjamin Kosnik 2006-08-31 22:20:20 UTC 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