NM, the bug I'm encountering is the same one here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115 On Mon, Jun 8, 2009 at 3:23 PM, Joseph Garvin<joseph.h.garvin@xxxxxxxxx> wrote: > 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. >>> >> >
