https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790
--- Comment #9 from nsz at gcc dot gnu.org --- i added an execution test that aborts on modern x86_64 when built as cc -c -o main.o main.c cc -Wl,-z,now -shared -fPIC -o lib.so lib.c -latomic cc -Wl,-rpath=. -o main main.o lib.so -lpthread -latomic because the library is bind now, its function calls are resolved before the libatomic ctor is run (so uses locking load_16/store_16), main is resolved lazily so it is after the ctor (so uses cmpxchg16). if in the same process libatomic ifunc can resolve to inconsistent synchronization function in different modules that's broken behaviour. note that an ifunc resolver has to be as-safe and thread-safe, so the attached patch has to be checked to initialize edx atomically. (i think it can be still broken if there is no direct DT_NEEDED dependency against libatomic from a library that uses libatomic calls: libatomic may not be relocated when the resolver in it is called) there are several targets that do not support ifuncs at all and it seems even where it is supported (glibc only) there are these issues so i'd prefer a solution where gcc can be built without ifunc in libatomic (currently that is broken too because libatomic has no fallback dispatch mechanism and gcc can decide to inline cmpxchg16).
