amd64 atomics: guard flag output operand use with feature test

[rlibby]

Summary

Allow old cross compilers to build base after r358439 & r358440.

To be honest, I'm not sure what the best direction here is. Options
seem to be:

• Revert and let intrinsics clean this up eventually, maybe with its own feature guards,
• Leave things how they lie now and don't worry about old cross compiler,
• Take this (rather ugly) patch.

Requested by: melifaro

Test Plan

kyua test -k /usr/tests/sys/Kyuafile

Manual inspection of generated code.

[mjg]

I think this is too much of an uglifier. Given this and the fact that the change is -CURRENT only (i.e., not going to be MFCed) I think looking out for older compilers is not worth it. I don't see a clear fix modulo copy-pasting the current routines and ifdefing around them.

The guarantee is that stable/12 can build -CURRENT but that is supposed to start with updating the toolchain thus it should not be a problem. One can sanity check that this is maintained.

[kib]

I believe this is overreaction and we should select no. 2, ie. do nothing.
In fact, what are the 'old cross-compilers', and what is the situation where somebody forced to use them to build current ?

Note that 12 has clang 9.0.1, 12.1 has 9.0 (from my memory), and 11 is on 8.0.1, might be 9.0.1.

[rlibby]

Okay, I am happiest to go with option #2 also. I'll leave this up for a little in case any one else has a comment.

This did cause one problem in practice. A port had pinned itself to llvm 7.0, and then failed to build because of this (a kernel module I think):
https://lists.freebsd.org/pipermail/freebsd-emulation/2020-March/017682.html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236616

Obviously the right solution is for the port to fix the bug instead of pin the compiler version, but anyway this is the closest to a real scenario that I know.

[mjg]

Can we kill this review?