Update 2: Actually, the use of inline ends up not being important, all that matters is you use __sync_add_and_fetch in one module but not the other. GCC must be silently upping the architecture setting for files that use __sync_add_and_fetch. This doesn't seem like a good idea. Besides doing something without telling the user, any configure test has to be more complex. On Mon, Jun 8, 2009 at 3:00 PM, Joseph Garvin<joseph.h.garvin@xxxxxxxxx> wrote: > Update: I think GCC silently decides your architecture supports atomic > builtins if you use them, and this causes problems if you inline uses > of them across modules. I think something here is a bug, I'm just not > sure what. > > Download the attachment and run: > > g++ atomic_int_gcc.cpp > > This file uses __sync_add_and_fetch directly and builds fine. Then try this: > > g++ the_inline_test.cpp inline_test_user.cpp > > In this case the_inline_test.cpp uses a function defined by > inline_test_user.cpp that uses an inline function that uses > __sync_add_and_fetch. It will result in a linker error. You have to > compile like this (assuming x86): > > g++ -march=i686 the_inline_test.cpp inline_test_user.cpp > > If the lock instruction has been around since the 386, why do I need > to specify i686? If I really do need to specify i686, why don't I need > to specify it for atomic_int_gcc.cpp? If this is by design, it seems > to violate the principle of least surprise. > > On Mon, Jun 8, 2009 at 2:32 PM, Joseph Garvin<joseph.h.garvin@xxxxxxxxx> wrote: >> I wasn't going to ask this because I thought it was peculiar to my >> custom build environment, but I discovered this is no longer true. >> >> If I manually call gcc to compile a file that uses the atomic built-in >> __sync_add_and_fetch, it compiles and links fine. But if I use it in >> an autotool'd project, linking will fail complaining that >> __sync_add_and_fetch doesn't exist. No custom march or cflags are >> being set. How is this possible? O_o Is there anyway that GCC will >> choose to compile with atomic builtins disabled without specifying a >> march flag? >> >> I've tried the manual compile with/without -D_REENTRANT, -g, and -O2 >> and it makes no difference. Always succeeds. The only other thing I >> can think of is that somehow what is *linked* against can cause GCC to >> drop atomic builtins. Is this known to happen? The implication is my >> configure test for the presence of __sync_add_and_fetch always >> succeeds even though my app won't build, defeating its point. >> >
