__builtin_ms_va_list support like gcc/llvm on Linux

jordan_j_1 · ‎09-19-2016

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!

jordan_j_1 · ‎09-20-2016

this appears to be the commit adding the x86_64-ms_abi / __builtin_ms_va_list support to LLVM; https://github.com/llvm-mirror/llvm/commit/7e96f0f6fffbdebfdac238ae76cc3a791acfa23e however, I'm still looking for the clang patch that goes with it. Another thought that I had was to roll over some of Wine's build scripts and find the place where ms_abi is defined in it's source tree and try to make something work, but obviously if ICC just supported __builtin_ms_va_list, that would make life much easier.

Judith_W_Intel · ‎09-21-2016

Is is true that this builtin is only useful for cross compilation? The Intel compiler does not support that -- GNU has the --target option but Intel does not.

Judy

jordan_j_1 · ‎09-21-2016

Well, I suppose it depends on how you define cross-compilation, technically, I guess it would be cross-compilation. However; In my example, I am not trying to build/cross-compile a windows application for use on a Windows machine, from a Linux machine... *** I'm trying to build a 64bit version Linux application (Windows Emulator) for use on a 64bit Linux machine; WIne; https://www.winehq.org/ ... the problem of course is that Linux x86_64 and MS x64 have different ABIs, so the compiler needs to account for that, which is why __builtin_ms_va_list is needed. GCC has been able to deal with Wine 64bit since gcc-4.4 and LLVM/Clang since last year...I think Wine falls into a bit of a grey area, since it's a native app, that runs windows binaries (on Linux/unix/MacOS). Maybe it would be possible to override Wine's configure check for __builtin_ms_va_list and then hack something in Wine itself to make ICC work correctly on Wine64bit compilation/use. I'd probably have to dig through it's source code and/or ask someone in 'the know', as off-hand I am not sure where the relevant code resides in Wine or what would be fully involved in doing such a hack (and it wouldn't be something I could then contribute back to the project, as they would just expect the compiler to support __builtin_ms_va_list, i think).

jordan_j_1 · ‎10-11-2016

Hi, I bumped into another use of __builtin_ms_va_list building 64bit libraries using Intel's cpiler on Linux. Here is the post; https://software.intel.com/en-us/forums/intel-c-compiler/topic/699453 thanks

SergeyKostrov · ‎10-12-2016

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? 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.

SergeyKostrov · ‎10-12-2016

This is the 2nd thread I've read related to __builtin_ms_va_list 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? 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 too many dependencies on Intel's technologies, like AVX2 ISA, Xeon CPUs, etc.

jordan_j_1 · ‎10-12-2016

Sergey Kostrov wrote:

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?

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).

Sergey Kostrov wrote:

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.

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.