But I don't think it's possible for a .NET method to use __vectorcall as its calling convention. The attribute used to specify it doesn't have a value for this: https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.unma...
It's possible MS will extend this in the future, but it's also possible they'll make up entirely new calling conventions. I don't think they will, and for now I don't think it's worth the extra complexity.
Is it the same for managed C++? If you say __vectorcall support is not needed I will of course remove this code.
Managed C++ is limited to what the runtime can generate for vtable fixups, and I can't find any indication that the runtime can generate __vectorcall functions. So I don't think it is needed.
If they do not support it they should just issue compiler warning, or am I missing something? Clang may hopefully add the suport. msvc is very unlikely to compile Wine soon I guess. Intel Compiler does not support ms_abi attribute at all and thus compiling wine 64bit with it is totally not feasible for now.
I don't know what compilers will be used in practice (some people build parts of wine with msvc, but probably not mscoree). I think we want GCC extensions to at least be inside a check for whether the compiler is GCC.
I can guess it might be just nearly as likely as without .NET. See this bug: https://bugs.winehq.org/show_bug.cgi?id=27680: there is 7-8 apps w/o .NET known so far. As I got from brief googling native .Net should not suffer from stack misalignment. So I thought it won't hurt to add an attribute to ReallyFixupVTable (which presumably will be universally supported some day) , but considered too much forcing alignment right in the thunk.
I think it's fine if we check for gcc (and I think clang may conveniently claim to be gcc), but I also don't think it's required at this point.
Are you sure they are going to crash?
I'm not sure, I did not look carefully. But they do seem to put effort into preserving alignment, in a way that assumes the stack is aligned on entry.