On Wed, 18 Feb 2026 at 09:33, Jonathan Wakely <[email protected]> wrote: > > On Tue, 17 Feb 2026 at 23:47, Sandra Loosemore <[email protected]> > wrote: > > > > On 2/17/26 16:07, Joseph Myers wrote: > > > On Tue, 17 Feb 2026, Jonathan Wakely wrote: > > > > > >>> Would the following be more accurate and more descriptive? > > >>> > > >>> @opindex fno-link-libatomic > > >>> @opindex flink-libatomic > > >>> @item -flink-libatomic > > >>> > > >>> Link with libatomic. Enabled by default. > > >>> > > >>> The compiler will add options to link to libatomic when it is > > >>> supported by the target, so that the atomic operations defined by > > >>> the C and C++ standards work without requiring explicit action from > > >>> users. Typically this adds @option{-latomic} to the link command > > >>> line; for the GNU linker @option{--as-needed} is also used. > > >>> The negative form @option{-fno-link-libatomic} can be used to > > >>> explicitly disable linking of libatomic. The options > > >>> @option{-nodefaultlibs} and @option{-nostdlib} will also disable > > >>> linking to libatomic. > > >> > > >> I suppose my use of "disabling" still has exactly the problem I > > >> complained about above. Using -fno-link-libatomic doesn't disable > > >> linking to libatomic, nor does -nodefaultlibs. When those options are > > >> used, users can still add -latomic themselves and that will work, so > > >> it hasn't been *disabled*. What the -fno-link-libatomic option does is > > >> disable the *automatic* linking to libatomic, or the *implicit* > > >> linking to libatomic. > > >> > > >> So I think this could still do with some more wordsmithing. > > > > > > One bit of wordsmithing would be that I think it's generally better to say > > > the compiler *does* something rather than "will" do it. So "adds options" > > > not "will add options", and likewise remove "will" in "will also disable" > > > (along with any change to avoid "disable" there). > > > > Yes, this is something I'm always fixing every time I see it: write in > > the present tense by default, and reserve the future tense for something > > that explicitly happens later (or that hasn't happened yet, like "this > > deprecated misfeature will be removed in a future release"). > > > > Anyway, even without that change I think the proposed replacement text > > is too verbose and too full of tangents. How about just > > > > @opindex fno-link-libatomic > > @opindex flink-libatomic > > @item -flink-libatomic > > @itemx -fno-link-libatomic > > Enable/disable linking with libatomic. This is enabled by default on > > targets that support it; to explicitly disable it, use > > @option{-fno-link-libatomic}. > > I prefer that to what we have in the docs today, do you want to make > that change or should I send a patch doing that?
Jakub explained to me that -flink-atomic is only enabled if the linker supports --as-needed, which the docs completely fail to explain. Just saying "on targets that support it" is inadequate. The option is on for targets which support libatomic *and* which support the --as-needed linker flag. So GNU ld,, gold, lld, mold, ... but *not* Solaris ld for example. > > I still think there's value in noting the interaction with > -nodefaultlibs and -nostdlib (otherwise I wonder if libatomic is a > "std" lib?). I also think there's value in noting that --as-needed is > used for GNU ld. But I can live without those bits.
