Date: Sun, 01 Jun 2025 19:52:34 -0700
> On Jun 1, 2025, at 7:34 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sunday, 1 June 2025 18:42:34 Brasilia Standard Time Oliver Hunt via Std-
> Proposals wrote:
>> The fact is that the windows C++ ABI is not the same as other platforms, and
>> that’s what compilers targeting windows should be using. Arguing otherwise
>> is no different from saying “long double on x86-64 darwin (maybe linux, I’m
>> not sure?) is fp80, so compilers should be able to use that abi on windows
>> despite it not being the case”/
> [cut]
>> In an ideal world compilers would emit code that conforms the the platform
>> ABI, rather than complaining that what is fundamentally incorrect codegen
>> not working.
>
> The platform ABI does not include C++. The processor-specific ABI (psABI) for
> each OS only covers calling sequence and standard types. The C++ ABI comes on
> top and it has a psABI portion for some low-level details.
By definition the *platform* defines the C++ ABI. It does not matter if there is another specification for what the ABI should look like, if the platform says “this is the ABI for calling a polymorphic function” that is the ABI for calling a polymorphic function. What you are trying to say is “if a platform provides a C++ interface, and that interface does not conform to an ABI definition that postdates the platform, the platform is wrong”. That’s nonsense. Again, the C++ spec does not say anything about vtables, and the documents you are referring to are, if anything, recommendations. If those documents do not match the platform’s ABI, you don’t get to then claim that your following of those recommendations trumps the ABI provided by the OS.
Literally the entire problem here can be summed up with “some compilers have decided that their preferred ABI is more important than the ABI defined by the host OS, and now people are acting like it is the OS’s fault for not supporting codegen that is not conforming to the host platform’s ABI”.
Again, the processor vendor does not define the ABI, the OS does. The processor vendor may make recommendations, but if those recommendations don’t match the OS, it is the job of the compiler to match the ABI presented by the OS.
This utter utter nonsense of “clang/gcc emits code but the OS is wrong so the code breaks” needs to stop.
It is the job of the compiler to ensure that the code it generates conforms to the ABI of the host platform. Not some idealized or preferred ABI. The host OS *cannot* change its ABI, the compiler can fix its codegen bugs.
Please note, I’m not saying the ABI presented by MSVC is “good”, and there are parts I’m sure people at MS would like to change, but they can’t.
The reality is that the ABI for C++ polymorphism on windows is not that same as that on other platforms, and that cannot change. To argue otherwise is to sit on the beach telling the tide not to come in.
—Oliiver
>
> On Sunday, 1 June 2025 18:42:34 Brasilia Standard Time Oliver Hunt via Std-
> Proposals wrote:
>> The fact is that the windows C++ ABI is not the same as other platforms, and
>> that’s what compilers targeting windows should be using. Arguing otherwise
>> is no different from saying “long double on x86-64 darwin (maybe linux, I’m
>> not sure?) is fp80, so compilers should be able to use that abi on windows
>> despite it not being the case”/
> [cut]
>> In an ideal world compilers would emit code that conforms the the platform
>> ABI, rather than complaining that what is fundamentally incorrect codegen
>> not working.
>
> The platform ABI does not include C++. The processor-specific ABI (psABI) for
> each OS only covers calling sequence and standard types. The C++ ABI comes on
> top and it has a psABI portion for some low-level details.
By definition the *platform* defines the C++ ABI. It does not matter if there is another specification for what the ABI should look like, if the platform says “this is the ABI for calling a polymorphic function” that is the ABI for calling a polymorphic function. What you are trying to say is “if a platform provides a C++ interface, and that interface does not conform to an ABI definition that postdates the platform, the platform is wrong”. That’s nonsense. Again, the C++ spec does not say anything about vtables, and the documents you are referring to are, if anything, recommendations. If those documents do not match the platform’s ABI, you don’t get to then claim that your following of those recommendations trumps the ABI provided by the OS.
Literally the entire problem here can be summed up with “some compilers have decided that their preferred ABI is more important than the ABI defined by the host OS, and now people are acting like it is the OS’s fault for not supporting codegen that is not conforming to the host platform’s ABI”.
Again, the processor vendor does not define the ABI, the OS does. The processor vendor may make recommendations, but if those recommendations don’t match the OS, it is the job of the compiler to match the ABI presented by the OS.
This utter utter nonsense of “clang/gcc emits code but the OS is wrong so the code breaks” needs to stop.
It is the job of the compiler to ensure that the code it generates conforms to the ABI of the host platform. Not some idealized or preferred ABI. The host OS *cannot* change its ABI, the compiler can fix its codegen bugs.
Please note, I’m not saying the ABI presented by MSVC is “good”, and there are parts I’m sure people at MS would like to change, but they can’t.
The reality is that the ABI for C++ polymorphism on windows is not that same as that on other platforms, and that cannot change. To argue otherwise is to sit on the beach telling the tide not to come in.
—Oliiver
Received on 2025-06-02 02:52:48