On 7 January 2017 at 20:32, Ed Smith-Rowland wrote:
> This is an interesting idea. ABI is not really a language problem so the
> idea might not catch here. ^H...^H. Actually, every time a language feature
> is added the ABIs have to add it.
>
> On the other hand portability ideas have been floated before and were found
> illuminating (There was a paper about standardizing an ABI and.. Hinnant?
> Can't remember.)

N4028

> One thing that pops into my mind is that even within one ABI we have to
> change it periodically. I'm thinking mostly library here.

The front-end has to change too, when bugs in the ABI implementation
are found, or the ABI isn't precise and two implementations decide to
handle passing of empty structs differently, for example.

> But even
> language ABI you might want to date rather than just 1 or 0. The library
> ABI would depend on library vendor more than chip vendor.
>
> Jason Merrill knows a lot about this I think.
>
> Ed
>
> __cpp_abi_itanium yyyymm
>
> ...
>
> __cpp_lib_abi_gnu yyyymm
>
> __cpp_lib_abi_msvc yyyymm
>
>
> I know both language and library ABI would change with compiler switches.

But not really in ways that are relevant to SD-6. The precise details
of how G++ behaves with different -fabi-version=N are vendor-specific
and can't be encoded in a vendor-neutral feature-test macro.

> In libstdc++ we can switch between a CoW string/list O(n)-size to a C++11
> string/O(1) list size world.

That choice is entirely vendor-specific, so is also not something SD-6
needs to care about.

I'm not even sure I see any value in a macro to identify Itanium vs
MSVC vs EABI etc. but if that's useful, a date that corresponds to the
revision of that ABI document is probably as detailed as we'd want.