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

Melanie Blower via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 19 12:15:52 PDT 2018


mibintc added a comment.

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



================
Comment at: include/llvm/ADT/BitmaskEnum.h:73
 
+#ifdef __INTEL_COMPILER
+template <typename E>
----------------
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. 


================
Comment at: include/llvm/Analysis/AliasAnalysis.h:254
   FMRB_OnlyAccessesInaccessibleOrArgMem = FMRL_InaccessibleMem |
-                                          FMRL_ArgumentPointees |
+                                          static_cast<int>(FMRL_ArgumentPointees) |
                                           static_cast<int>(ModRefInfo::ModRef),
----------------
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.


================
Comment at: lib/Target/AMDGPU/SIISelLowering.cpp:6131
 
+#ifndef __INTEL_COMPILER
         static_assert(((~(SIInstrFlags::S_NAN |
----------------
this assesrts with Intel compiler?  Or the expression needs to be rewritten with static_cast as above?


https://reviews.llvm.org/D44426





More information about the cfe-commits mailing list