I've tested it on Windows with 64-bit icl
These are mostly workarounds for https://software.intel.com/en-us/comment/1919743 , https://software.intel.com/en-us/forums/intel-c-compiler/topic/749369 and few more enum-related issues
Differential D44426
Fix llvm + clang build with Intel compiler yvvan on Mar 13 2018, 7:07 AM. Authored by
Details I've tested it on Windows with 64-bit icl These are mostly workarounds for https://software.intel.com/en-us/comment/1919743 , https://software.intel.com/en-us/forums/intel-c-compiler/topic/749369 and few more enum-related issues
Diff Detail Event TimelineComment Actions I don't follow. What should we do then? If LLVM doesn't compile on a compiler which we claim is supported, then how should we proceed? Comment Actions Is that compiler really supported? Look at this: void operator delete(void *) = delete; It's been there in the code since early 2015. The bitwise OR on ELF::xxx has been there even longer. Are you telling me that we officially support a compiler, but nobody has actually used it for more than 3 years? What's going on here? Comment Actions @nhaehnle And that's the problem. There's no build machine for intel compiler and nobody cares. That's why I suggest this patch to at least make people know that it's possible to build. Or probably to grab someone's interest to the problem and set up builds. Comment Actions I added some inline comments. You are using the Intel 18.0 compiler on Windows - what version of Visual Studio is in the environment?
Comment Actions Yes, I'm using 18.0
|
I really think all the Intel-compiler bug workarounds should be version specific. For example, in the boost.org customizations we have checks like this:
#if defined(INTEL_COMPILER) && (INTEL_COMPILER >= 1500)
I believe you are using the most recent Intel compiler, 18.0, which has version 1800. Let's assume the bug will either be fixed in our 18.0 compiler or in our next compiler which would be numbered 1900, so the check could be like this:
#if defined(INTEL_COMPILER) && (INTEL_COMPILER < 1900) // employ the workaround for the Intel 18.0 compiler and older
This way the workaround will "disappear" when the bug gets fixed.
For that matter I wonder if it's still necessary to use the workaround for the Microsoft compiler?
Thanks for reporting the bug into the Intel forum. If we put a bug workaround into LLVM it would be very nice to have the bug reported to the offending compiler.