I'm curious if anyone knows where or not Intel is planning on adding __builtin_ms_va_list support to their compiler?
I had asked this question a few years ago, to which it didn't seem like anyone was certain... I've recently (with the release of the 2017 edition) taken another look at this, half-assuming that at this point Intel would have added the support. Being compatible with GCC6, I would tend to think __builtin_ms_va_list would be available, since it has existed in GCC for many years...
Anyway, without this - I'm stuck on trying to build Wine 64bit on Linux with icc. I'd be interested to know if anyone else has been trying to, or even has been successfully able to get wine 64bit working with icc; even if it requires a bit of a hack (patches welcome!), I would be interested. thanks!
Sergey Kostrov wrote:Hey Sergey, I 100% get what you are saying. However, I would point out that Clang/LLVM and GCC *are* Major C/C++ Compilers, more widely used than Intel's Compiler and arguably more than many other C/C++ compilers too (MSVC aside, Windows dominates PC industry, obviously). * I personally think that Intel's compiler should support this kind of thing because Intel target's these platforms. GCC and Clang/LLVM are not obscure compilers on Mac(Darwin)/Unix or Linux (or android/iOS for that matter) ~ they are the STANDARD compilers/toolchains. But to answer your other question: I'm 'locked' into these features because of ABI / data model differences on 64bit systems between Windows and Linux/Unix; https://en.wikipedia.org/wiki/LP64#64-bit_data_models ...and because __builtin_ms_va_list is the defacto method used by the standard compilers on Unix/Linux/Mac 64bit systems to address/resolve these differences/portability problems. I also do not think that Mesa or Wine developers need to fix there code or address this issue. They already have their 64bit code working on the two most widely compilers on the platforms where these libraries/applications are used. (Obviously, niether are applicable/used on Windows).
This is the 2nd thread I've read related to __builtin_ms_va_list /strong> and I can't understand why on some Open Source projects developers are Not taking into account possible Non-Portability problems seriously.
Major C++ compilers will never (!) be fully compatible. If Open Source developers are using some incompatible extensions and don't think in advance about supporting as many as possible C++ compilers then why Intel C++ compiler should support it?
The problem actually needs to be addressed to MESA and Wine Open Source projects developers and the question is Why are you "locked" on these incompatible features?
Sergey Kostrov wrote:Yeah, I that you are just expressing your own opinions... Interesting, I'm not really surprised that it would have many dependencies on Intel's technologies; Intel wants to leverage their own technologies as much as possible.
PS: By the way, I don't defend Intel and I simply express my opinion as a C++ Software Engineer working on a project with support of 6 major versions of C++ compilers. I'm also very concerned about Intel's new Open Source project MKL DNN because it has to many dependencies on Intel's technologies, like AVX2 ISA, Xeon CPU, etc.