On Monday, 15 January 2024 07:52:31 PST Arthur O'Dwyer wrote:
> Every ABI has such failures, to some extent. (The problem is that ABIs by
> definition are fixed artifacts, whereas the paper standard keeps moving
> and/or fixing its own bugs.) For example, lately I've been looking at
> exception handling. The Itanium ABI miscompiles the following program: void
> f() { static int i; throw &i; }
> int main() { try { f(); } catch (void*&) {} catch (const void*&) {
> puts("OK"); } } by taking the first catch block instead of the second.
> That's because the Itanium ABI simply does not preserve enough information
> in RTTI to distinguish those two catch-blocks' types. See:
> https://quuxplusone.github.io/blog/2023/11/17/reinterpret-cast-via-throw/
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23257

Sure, there are known bugs in the Itanium ABI indeed. There's a document for
"stuff we need to fix when we break BC", though it's also something that could
be applied immediately to any new architectures (should have been done for
AArch64 for this issue, for example, because it didn't exist when the issue
was detected).

But I argue that those are very narrow corner cases, for the most part. That's
different from MSVC's problems, which are far more blatant. The distance in
time between the two ABIs is not that great: the Itanium ABI came about with
Itanium in 1999, and the MSVC's ABI is from about Microsoft C/C++ 7.0 in 1992.
The big difference is that MSVC's is pre-standard.

> Another perennial ABI woe (present on all platforms I'm aware of) is that
> e.g. `unique_ptr` can't be passed in a register.
> https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/

That's a performance optimisation, so not really visible to the user and thus
not affecting conformance with C++.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering