[PATCH] D44426: Fix llvm + clang build with Intel compiler

[Ivan Donchevskii via Phabricator via cfe-commits]

yvvan added a comment.

In https://reviews.llvm.org/D44426#1042162, @mibintc wrote:

> I added some inline comments. You are using the Intel 18.0 compiler on Windows - what version of Visual Studio is in the environment?


Yes, I'm using 18.0



================
Comment at: include/llvm-c/Target.h:25
 
-#if defined(_MSC_VER) && !defined(inline)
+#if defined(_MSC_VER) && !defined(inline) && !defined(__INTEL_COMPILER)
 #define inline __inline
----------------
mibintc wrote:
> 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. 
> 
This one will probably not be fixed because I was answered that it's the predicted behavior and that I need not to "#define inline __inline" if I use intel compiler
I agree though about versions which need to be taken into account


================
Comment at: include/llvm/ADT/BitmaskEnum.h:73
 
+#ifdef __INTEL_COMPILER
+template <typename E>
----------------
mibintc wrote:
> what problem is being worked around here? I checked your post into the Intel compiler forum "enum members are not visible to template specialization" and I can observe the bug on our Windows compiler but not our Linux compiler. 
it was recently accepted. the issues is that E::LLVM_BITMASK_LARGEST_ENUMERATOR from line 80 here is always invalid with intel compiler and the whole set of operator overloads is ignored
at least on Windows :)


================
Comment at: include/llvm/Analysis/AliasAnalysis.h:254
   FMRB_OnlyAccessesInaccessibleOrArgMem = FMRL_InaccessibleMem |
-                                          FMRL_ArgumentPointees |
+                                          static_cast<int>(FMRL_ArgumentPointees) |
                                           static_cast<int>(ModRefInfo::ModRef),
----------------
mibintc wrote:
> is this a necessary workaround for the Intel compiler? It's not pretty.  Suggest we add the #if around it? Long term i hope this would not be necessary.
i'm not sure that adding #if around makes it easier to understand :)
of course I can add it everywhere I append enums with static_cast<int>


================
Comment at: lib/Target/AMDGPU/SIISelLowering.cpp:6131
 
+#ifndef __INTEL_COMPILER
         static_assert(((~(SIInstrFlags::S_NAN |
----------------
mibintc wrote:
> this assesrts with Intel compiler?  Or the expression needs to be rewritten with static_cast as above?
"needs to be rewritten with static_cast" - correct. it can be done but I was a bit lazy and statioc_assert does not affect the outcome of build :)


https://reviews.llvm.org/D44426