On Wed, 18 Feb 2026 at 15:13, Jonathan Wakely <[email protected]> wrote: > > 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.
Actually it looks like Solaris ld supports the option too ... but not all linkers do, and that affects when -flink-libatomic is on by default. > > > > > > 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.
