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:gccClassification:UnclassifiedComponent:libstdc++Version:4.2.0

Descriptionbero 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 todayresults inLinking CXX executable dummyindexerCMakeFiles/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' followcollect2: ld returned 1 exit status

Comment 1Andrew Pinski2006-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 2bero 2006-08-09 22:54:01 UTC

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

Comment 3Paolo Carlini2006-08-09 23:08:24 UTC

First, a general remark: this kind of error must never happen, irrespective ofthe options used to build user code and/or GCC.Then, it looks like _GLIBCXX_ATOMIC_BUILTINS is defined for that installationof GCC. In turn, this is not supposed to happen for ?86, *any* ?. Eithersomething is wrong in the installation (something was forced overriding theconfigure 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 usingstring will not link, no complex applications are needed to reproduce.

Comment 4Paolo Carlini2006-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 ofatomicity.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 GCCin a totally clean way and trying again.

Comment 5Paolo Carlini2006-08-09 23:48:31 UTC

Benjamin, in case this problem is confirmed (and some strange details of the PRare sorted out), can you please double check that we are not incurring in theissue I was fearing here:  http://gcc.gnu.org/ml/libstdc++/2006-07/msg00088.html???Thanks a lot!

Comment 6bero 2006-08-09 23:55:12 UTC

Ok, misunderstanding about the compiler flags -- -march=i586 was used to buildthe compiler, strigi was built without any -march= tags (making the defaulti386, 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 7Andrew Pinski2006-08-09 23:58:20 UTC

Can you give your exact commands use to build GCC?

Comment 8Paolo Carlini2006-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 thatmessage. The problem seems to be that the autoconf testGLIBCXX_ENABLE_ATOMIC_BUILTINS is *always* run (irrespective of the details ofconfigure.host), thus _GLIBCXX_ATOMIC_BUILTINS defined for your GCC buildflags, and then you have always to use -march=i486 (or higher) when compilingyour code. Annoying to say the least. We don't want that. Thanks for yourreport.

Comment 9tim blechmann2006-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-gnuConfigured 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=gnuThread model: posixgcc version 4.2.0-alpha20060812  (experimental) (Gentoo 4.2.0_alpha20060812)the cflags and cxxflags to build gcc were: -march=pentium-m -pipe -O2would be great, to have this resolved, soon ...

Comment 10Paolo Carlini2006-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 11Paolo Bonzini2006-08-25 07:09:59 UTC

Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testingfor __sync_fetch_and_add support) that the compiler should provide it as apreprocessor symbol.If you move cpu/generic/atomicity_{builtins,mutex}/atomicity.h toinclude/bits/atomicity_{builtins,mutex}.h, cpu/generic/atomicity.h can besimply:#include <bits/atomicity.h>#ifdef __ATOMIC_BUILTINS__#include <bits/atomicity_builtins.h>#else#include <bits/atomicity_mutex.h>#endifSimilarly, 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 12Paolo Carlini2006-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 onit, per:  http://gcc.gnu.org/ml/libstdc++/2006-07/msg00103.html  http://gcc.gnu.org/ml/libstdc++/2006-07/msg00106.htmlbut, as I said, you are very welcome. That symbol would be immediately usefulfor 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 finegrained info about the sub-target on x86, Sparc, for example, because we wantuser code independent from the atomicity model, without going for mutexeseverywhere (old story about distros: don't want to prepare separate distros fori386 and i486): in such cases the atomicity routines must remain out-of-line inthe compiled library. However, that reasoning means that, as I suggestedalready, in those cases you could exploit anyway the dynamical preprocessorbuiltin when building the routines in the out-of-line library (that wouldenable exploiting the builtins on i486+ for example). Much more sophisticatedapproaches, optimal in every case, are possible only by way of multilibs, AFAIK(also discussed a lot in the past).Agreed?

Comment 13Benjamin Kosnik2006-08-28 09:49:35 UTC

Just a note. The current behavior is as intended, although perhaps not documented. I'll befixing 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.htmlWhat this means is that people building gcc with -march flags then need toconsistently pass those same flags around when using the compiler. Yes, this isa pain. We're working on a better way to do this.The real issue is: "code independent from the atomicity model." The only way tohave this is to not inline the atomic helper functions in atomicity.h. I amwilling to revert that part of my July atomics config change. Although I would prefer not to. -benjamin

Comment 14Paolo Carlini2006-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 arealways available, irrespective of the subtarget, that's fine of course. I thinhwe can leave with that, frankly: for strings we are moving away from referencecounting anyway; when running single-thread now we don't call the atomicfunctions; finally, for things like shared_ptr we can have the fine-grainedpreprocessor builtin and everything is nice.

Comment 15Paolo Carlini2006-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 16Benjamin Kosnik2006-08-31 09:08:05 UTC

Mine.

Comment 17Benjamin Kosnik2006-08-31 10:46:08 UTC

Subject: Bug 28671Author: bkozDate: Thu Aug 31 10:45:59 2006New Revision: 116601URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116601Log:2006-08-31  Benjamin Kosnik  <[e-mail]>    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 18Andrew Pinski2006-08-31 16:59:56 UTC

Fixed.

Comment 19Benjamin Kosnik2006-08-31 22:20:20 UTC

Subject: Bug 28671Author: bkozDate: Thu Aug 31 22:20:09 2006New Revision: 116608URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116608Log:2006-08-31  Benjamin Kosnik  <[e-mail]>    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