https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- I should also note the testsuite point I mentioned in the BoF, and related points about building target libraries, which mean this is more complicated than just the driver specs change: There is testsuite logic (see gcc/testsuite/lib/atomic-dg.exp) to locate libatomic for build-tree testing and set appropriate -L options and LD_LIBRARY_PATH. This is only used in gcc/testsuite/gcc.dg/atomic/atomic.exp at present. If the driver specs change to use "--as-needed -latomic --no-as-needed" whenever libatomic is built (obviously they shouldn't do so for configurations not building libatomic, whether because unsupported for the target or because disabled at configure time), linking *any* target program will then require libatomic to be somewhere that ld can find it (because ld requires a library named with -l to be somewhere it can find, even inside --as-needed; it can only know whether a library is needed after seeing what symbols it defines). Thus, that logic would need to be used globally for all testsuites. In addition, all configure tests in target libraries that run link tests, and linking of shared target libraries, would need to pass appropriate -L options to find libatomic, and we'd need to make sure the target library dependencies in toplevel Makefile.def ensure libatomic is built before other target libraries are configured for this to work. I think libgcc should still be built before libatomic and so we'd need some driver option to disable linking with libatomic that would be passed when linking shared libgcc.