On Wednesday, 31 December 2025 11:26:46 Brasilia Standard Time Frederick
Virchanza Gotham via Std-Proposals wrote:
> We can already use the "-march" flag to produce object files that won't work
> together, I mean I can do:
>
> g++ -c a.cpp -march=armv9-a
> g++ -c b.cpp -march=x86-64

No you can't, not with GCC. Clang has the -target option, but GCC cross-
compilers are *different* binaries.

The -march and -mtune options produce ABI-compatible binaries (at least on x86
and I think on AArch64 too). There are ABI-changing -m options, but -march and
-mtune aren't.

In any case, off-topic.

> "x86-64-v2" is however a superset of "x86-64", and if I understand you
> correctly Jonathan, then what you're saying is that an "x86-64-v2" object
> file must be compiled in such a way so that it will link successfully and
> work properly with other object files compiled with x86-64, or x86-64-v3,
> or x86-64-v4. Do I understand correctly? That is to say, those four
> architectures are considered to be a family, and all family members must be
> intercompatible, right?

Correct.

I don't know what GCC devs call them. I called them "sub-architecture" when I
tried to develop a solution for CMake to automatically compile a target for
multiple of them. I didn't go far.

> I also think it means that x86-64-v2 users suffer an unnecessary performance
> penalty (i.e. jumping into a function that contains a 'cmpxchg16b'
> instruction instead of just placing the instruction inline).

Correct. Similarly, x86-64-v3 must emit VZEROUPPER before any function call if
it has used YMM registers, which is also a performance penalty. Though for
this one there is an ABI-changing -m option: -mno-vzeroupper.

> How about having a new command line option, "-m1"?

I think "patches accepted", like -mno-vzeroupper. And I'd recommend also
adding a configure-time option to make it the default, for whoever may want to
use it.

> because the compile-time value of atomic< __uint128_t >::is_always_lock_free
> has implications for my proposed new standard library type:
> std::atomic_pointer_pair.

Why? The value would be QoI anyway, so why would a compiler change make any
impact to standard proposal?

And besides, your type is just std::atomic<std::pair<void *, void *>> anyway
(though that violates the rule of std::pair use: NEVER).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.