Forgive me if this sounds like a cheeky question but wouldn't it make sense for mingw to use the same name-mangling scheme as other Windows compilers? I recently spent some time experimenting with clang (on Windows) and I was pleasantly surprised to find that it uses the same name-mangling scheme as MSVC (which means that C++ libraries can be freely interchanged between them). For mingw, this is only possible with conventional 'C' libraries, which don't use name mangling.
In fact I've occasionally seen references to ms-mangling in discussions about mingw but I wasn't able to find out much about it. Does it exist? Or just something that users have been asking about?
Last edit: John Emmas 2023-11-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, there is no point to making gcc name mangling compatible with MSVC, the ABI is incompatible, so even if it would make the linker work, the program would crash.
GCC has its own runtime C++ libraries, so it has a different way of calling C++ functions from MSVC. C functions work because they are simple enough to interface and don't have any gotchas anywhere.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks Jonathan - so when I've occasionally seen a reference to 'ms-mangling', presumably that's something that programmers were asking for but in practice, it doesn't exist?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's correct, in terms of cross compiler compatibility, there is no reason to be compatible since C++ is a complex enough language to have vastly different implementations underneath.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clang manages this quite well though, supporting at least three different ABIs (Mac, MSVC, MinGW, Linux, ...) in one compiler. Also the Intel compiler used to implement the MSVC ABI details as well. So the idea isn't far-fetched. It's more that GCC doesn't have this feature (and probably never will).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again guys although in some ways that's a pity. GCC is a great compiler but for Windows use it'd be good to be able to integrate modules built either with MinGW, MSVC or Clang. In fact, even for plain old 'C' GCC sometimes isn't compatible... e.g. we've found it best to use 0-byte struct packing here because for normal packing (8-bytes) MinGW and MSVC sometimes don't agree on the layout for different elements in a struct :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again guys although in some ways that's a pity. GCC is a great
compiler but for Windows use it'd be good to be able to integrate modules
built either with MinGW, MSVC or Clang. In fact, even for plain old 'C' GCC
sometimes isn't compatible... e.g. we've found it best to use 0-byte struct
packing here because for normal packing (8-bytes) MinGW and MSVC sometimes
don't agree on the layout for different elements in a struct :-(
Haha, I doubt I'm close enough to Microsoft to suggest that! But out of interest, what are the big ABI differences? From past experience I know that member alignment in structs can be an issue but are there others? Calling conventions or whatever?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After a bit more reading I learned that the early C++ standards didn't apparently address struct packing so each compiler was free to implement it differently - hence the incompatibilities - but having said that...
These days the other common Windows compilers seem to agree on struct alignment so wouldn't it make sense for MinGW to join the club? I'm not referring to gcc generally of course - only MinGW. Or are there too many other factors to consider?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thing is, Windows-directed interest in GCC is minimal at best, I'm surprised at this point it still even works.
On the LLVM/Clang side, there was interest from, well, almost all big parties, including GPU vendors, to get the thing working well and cooperating with the rest of the Windows ecosystem. Microsoft themselves contributed some bits and pieces to the Windows codegen, and even ship Clang in their Visual Studio installers as an optional component.
It always comes down to manpower. MinGW(-w64) works well, and there's little reason to pull open the septic tank that is ABI compatibility, because it's probably just not worth the effort to anyone, especially give the fact that Clang is already a different compiler that does support it all (well, most of it).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I understand the manpower issue and even among Windows app programmers, MinGW isn't as popular as it should be - but surely lack of compatibility is the main reason for that? For example IIUC, MinGW still needs to use a very old version of the MS runtime modules - i.e. before name-mangling got introduced. And in turn, that means it uses a very old memory manager (meaning that memory pointers aren't guaranteed to be compatible between MinGW and anything else...)
So there's two big ABI problems that'd go away if the devs could work towards compatible name-mangling. In fact, I'd imagine they're probably the two biggest issues?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Mesmerized by the soulful rhythm, this song beautifully echoes the sentiments of love. In the midst of challenges, the bond remains unbroken. 🎶💕 #HeartfeltMelody #LoveBeyondBounds #SignsInmateLovesYou"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Mesmerized by the soulful rhythm, this song beautifully echoes the sentiments of love. In the midst of challenges, the bond remains unbroken. 🎶💕 #HeartfeltMelody #LoveBeyondBounds #SignsInmateLovesYou"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recently spent some time experimenting with clang (on Windows) and I was pleasantly surprised to find that it uses the same name-mangling scheme as MSVC
I've attempted to fix at least the first <auto> issue at one point, but abandoned the work when ran into commits such as this, which suggests to me at least some of the incompatibilities are in fact intentional.
MSVC can't keep the story straight either in those edge cases
Observe: https://godbolt.org/z/T75EzGf4a
(MSVC 19.28 and 19.30 are supposed to be binary compatible)
Last edit: Lennox Ho 2024-01-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, it looks like those bug reports are quite old ones so it's disappointing if they're still not fixed. AFAIK Microsoft enouraged LLVM/Clang's participation with Visual Studio so you'd think it would've been part of the deal for name-mangling to be compatible. There's a VS developer community here if you want to report the problem or ask a question there:-
Name mangling on Windows typically refers to the process by which the names of functions in a C++ program are altered by the compiler to incorporate information about their arguments. This is primarily done to support function overloading , where multiple functions can have the same name but different parameter types.
Last edit: thedigitalworld010 2024-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is logical for MinGW to adopt the same name-mangling scheme as other Windows compilers in order to enhance compatibility with C++ libraries. Although there have been discussions and mentions of "ms-mangling," it is important to note that it is not currently a standard feature of MinGW. Despite user interest, the implementation of this feature is still pending.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Forgive me if this sounds like a cheeky question but wouldn't it make sense for mingw to use the same name-mangling scheme as other Windows compilers? I recently spent some time experimenting with clang (on Windows) and I was pleasantly surprised to find that it uses the same name-mangling scheme as MSVC (which means that C++ libraries can be freely interchanged between them). For mingw, this is only possible with conventional 'C' libraries, which don't use name mangling.
In fact I've occasionally seen references to ms-mangling in discussions about mingw but I wasn't able to find out much about it. Does it exist? Or just something that users have been asking about?
Last edit: John Emmas 2023-11-18
No, there is no point to making gcc name mangling compatible with MSVC, the ABI is incompatible, so even if it would make the linker work, the program would crash.
GCC has its own runtime C++ libraries, so it has a different way of calling C++ functions from MSVC. C functions work because they are simple enough to interface and don't have any gotchas anywhere.
Many thanks Jonathan - so when I've occasionally seen a reference to 'ms-mangling', presumably that's something that programmers were asking for but in practice, it doesn't exist?
That's correct, in terms of cross compiler compatibility, there is no reason to be compatible since C++ is a complex enough language to have vastly different implementations underneath.
Clang manages this quite well though, supporting at least three different ABIs (Mac, MSVC, MinGW, Linux, ...) in one compiler. Also the Intel compiler used to implement the MSVC ABI details as well. So the idea isn't far-fetched. It's more that GCC doesn't have this feature (and probably never will).
Thanks again guys although in some ways that's a pity. GCC is a great compiler but for Windows use it'd be good to be able to integrate modules built either with MinGW, MSVC or Clang. In fact, even for plain old 'C' GCC sometimes isn't compatible... e.g. we've found it best to use 0-byte struct packing here because for normal packing (8-bytes) MinGW and MSVC sometimes don't agree on the layout for different elements in a struct :-(
On Tue, Nov 21, 2023, 11:27 John Emmas johne53@users.sourceforge.net
wrote:
You could ask Microsoft to support the GCC ABI :)
Haha, I doubt I'm close enough to Microsoft to suggest that! But out of interest, what are the big ABI differences? From past experience I know that member alignment in structs can be an issue but are there others? Calling conventions or whatever?
After a bit more reading I learned that the early C++ standards didn't apparently address struct packing so each compiler was free to implement it differently - hence the incompatibilities - but having said that...
These days the other common Windows compilers seem to agree on struct alignment so wouldn't it make sense for MinGW to join the club? I'm not referring to gcc generally of course - only MinGW. Or are there too many other factors to consider?
Nobody's stopping you :).
Thing is, Windows-directed interest in GCC is minimal at best, I'm surprised at this point it still even works.
On the LLVM/Clang side, there was interest from, well, almost all big parties, including GPU vendors, to get the thing working well and cooperating with the rest of the Windows ecosystem. Microsoft themselves contributed some bits and pieces to the Windows codegen, and even ship Clang in their Visual Studio installers as an optional component.
It always comes down to manpower. MinGW(-w64) works well, and there's little reason to pull open the septic tank that is ABI compatibility, because it's probably just not worth the effort to anyone, especially give the fact that Clang is already a different compiler that does support it all (well, most of it).
Yeah, I understand the manpower issue and even among Windows app programmers, MinGW isn't as popular as it should be - but surely lack of compatibility is the main reason for that? For example IIUC, MinGW still needs to use a very old version of the MS runtime modules - i.e. before name-mangling got introduced. And in turn, that means it uses a very old memory manager (meaning that memory pointers aren't guaranteed to be compatible between MinGW and anything else...)
So there's two big ABI problems that'd go away if the devs could work towards compatible name-mangling. In fact, I'd imagine they're probably the two biggest issues?
"Mesmerized by the soulful rhythm, this song beautifully echoes the sentiments of love. In the midst of challenges, the bond remains unbroken. 🎶💕 #HeartfeltMelody #LoveBeyondBounds #SignsInmateLovesYou"
"Mesmerized by the soulful rhythm, this song beautifully echoes the sentiments of love. In the midst of challenges, the bond remains unbroken. 🎶💕 #HeartfeltMelody #LoveBeyondBounds #SignsInmateLovesYou"
I just realised that since the middle of 2023 there's been a sharp drop in forum replies here... so is there now a better place for mingw questions?
I believe the LLVM folks always claimed it's best effort
https://github.com/llvm/llvm-project/issues/51342
https://github.com/llvm/llvm-project/issues/59246
https://github.com/llvm/llvm-project/issues/45314
https://github.com/llvm/llvm-project/issues/43552
I've attempted to fix at least the first
<auto>issue at one point, but abandoned the work when ran into commits such as this, which suggests to me at least some of the incompatibilities are in fact intentional.MSVC can't keep the story straight either in those edge cases
Observe: https://godbolt.org/z/T75EzGf4a
(MSVC 19.28 and 19.30 are supposed to be binary compatible)
Last edit: Lennox Ho 2024-01-29
Yeah, it looks like those bug reports are quite old ones so it's disappointing if they're still not fixed. AFAIK Microsoft enouraged LLVM/Clang's participation with Visual Studio so you'd think it would've been part of the deal for name-mangling to be compatible. There's a VS developer community here if you want to report the problem or ask a question there:-
Developer Community (visualstudio.com)
(maybe it just slipped through the net and hasn't been noticed yet...)
Name mangling on Windows typically refers to the process by which the names of functions in a C++ program are altered by the compiler to incorporate information about their arguments. This is primarily done to support function overloading , where multiple functions can have the same name but different parameter types.
Last edit: thedigitalworld010 2024-05-20
It is logical for MinGW to adopt the same name-mangling scheme as other Windows compilers in order to enhance compatibility with C++ libraries. Although there have been discussions and mentions of "ms-mangling," it is important to note that it is not currently a standard feature of MinGW. Despite user interest, the implementation of this feature is still pending.