This bugzilla service is closed. All entries have been migrated to
Bug 1122 - Eigen fails to compile with VS2015 clang-3.7 toolchain
Summary: Eigen fails to compile with VS2015 clang-3.7 toolchain
Alias: None
Product: Eigen
Classification: Unclassified
Component: General (show other bugs)
Version: 3.3 (current stable)
Hardware: x86 - 64-bit Windows
: Normal Compilation Problem
Assignee: Nobody
: 1127 1128 (view as bug list)
Depends on:
Reported: 2015-11-30 22:27 UTC by patrikhuber
Modified: 2019-12-04 15:13 UTC (History)
5 users (show)

Fix asm calls with clang/msvc (2.50 KB, patch)
2015-12-07 15:17 UTC, Gael Guennebaud
no flags Details | Diff
CLANG/MSVC fixes (4.59 KB, patch)
2015-12-07 15:39 UTC, Gael Guennebaud
no flags Details | Diff

Description patrikhuber 2015-11-30 22:27:21 UTC
Visual Studio 2015 Update 1 added an option to switch to compile with the clang frontend (the backend is still Microsoft's). They call the new toolset "Clang 3.7 with Microsoft CodeGen (v140_clang_3_7)".

Eigen fails to compile under that toolchain, with errors mostly related to inline assembly. I guess that's sort of expected, since the various #define's for different compilers/architectures break down in that configuration. I'm not sure how much of that is on Microsoft, or if it can be fixed within Eigen.

The errors are as follows:

1>C:\eigen-3.3-alpha1\Eigen/src/Core/util/Memory.h(870,5): error : GNU-style inline assembly is disabled
1>      EIGEN_CPUID(abcd,0x4,cache_id);
1>      ^
1>  C:\eigen-3.3-alpha1\Eigen/src/Core/util/Memory.h(840,17) :  note: expanded from macro 'EIGEN_CPUID'
1>          __asm__ __volatile__ ("xchg{q}\t{%%}rbx, %q1; cpuid; xchg{q}\t{%%}rbx, %q1": "=a" (abcd[0]), "=&r" (abcd[1]), "=c" (abcd[2]), "=d" (abcd[3]) : "0" (func), "2" (id));
1>                  ^

The same error in various other locations.

1>C:\eigen-3.3-alpha1\Eigen/src/Core/arch/SSE/PacketMath.h(444,85): error : member reference base type 'const Packet4f' (aka 'const __m128') is not a structure or union
1>  template<> EIGEN_STRONG_INLINE float  pfirst<Packet4f>(const Packet4f& a) { return a.m128_f32[0]; }
1>                                                                                     ~^~~~~~~~~
1>C:\eigen-3.3-alpha1\Eigen/src/Core/arch/SSE/PacketMath.h(445,85): error : member reference base type 'const Packet2d' (aka 'const __m128d') is not a structure or union
1>  template<> EIGEN_STRONG_INLINE double pfirst<Packet2d>(const Packet2d& a) { return a.m128d_f64[0]; }
1>                                                                                     ~^~~~~~~~~~

1>C:\eigen-3.3-alpha1\Eigen/src/Core/products/GeneralBlockPanelKernel.h(2002,3): error : GNU-style inline assembly is disabled
1>    ^
1>  C:\eigen-3.3-alpha1\Eigen/src/Core/util/Macros.h(533,42) :  note: expanded from macro 'EIGEN_ASM_COMMENT'
1>      #define EIGEN_ASM_COMMENT(X)  __asm__("#" X)

Same or similar error in a lot of other places too.

There could be more errors, clang stops compiling after this because of too many errors.
Comment 1 Gael Guennebaud 2015-12-01 13:50:01 UTC
We are going to need some help to handle that toolchain, that is, to properly activate the different workarounds.. 

First thing is to precisely known which compiler flags are pre-defined.
Comment 2 patrikhuber 2015-12-05 11:15:55 UTC
There was a post from MS yesterday that sheds some light on the defines. See the table a bit further down the post.
Comment 3 Gael Guennebaud 2015-12-07 15:17:03 UTC
Created attachment 632 [details]
Fix asm calls with clang/msvc

Here is a first attempt. Please try it and feel-free to play around to fix the other similar issues which might occurs...
Comment 4 Gael Guennebaud 2015-12-07 15:31:25 UTC
*** Bug 1127 has been marked as a duplicate of this bug. ***
Comment 5 Gael Guennebaud 2015-12-07 15:33:19 UTC
*** Bug 1128 has been marked as a duplicate of this bug. ***
Comment 6 Gael Guennebaud 2015-12-07 15:39:55 UTC
Created attachment 633 [details]

Patch update to handle operator= tricks.
Comment 7 patrikhuber 2018-04-28 13:25:57 UTC
I think we could consider closing this. I think that Microsoft is phasing out support for their Clang/C2 setup, since their compiler is now pretty much standard-conforming.

I am quoting Andrew Pardoe's (from Microsoft) comment below, from this blog post ( (I couldn't find out how to link to the comment directly)

>> The century has just started so it’s bold to make predictions, but I’ll give it a shot. Our team did Clang/C2 as an experiment. Standards conformance work in our compiler was in its early stages and we had already built most of Clang/C2 for a project in Windows called Islandwood. The idea was that developers would find it useful to have a Standards-conforming compiler for some parts of their code that they could link with MSVC-generated code.

>> After running this experiment for a while we’ve decided that it wasn’t successful. The MSVC compiler is now very close to full conformance with C++98/11/14/17 features and we expect that we’ll reach full feature parity in the VS2017 timeframe. And we’ve done a lot of work to help Clang and LLVM maintainers to make Clang/LLVM for Windows work well with our binaries and standard libraries.

>> My advice is to try MSVC for your code. Most developers find that with the /permissive- switch MSVC will compile code that Clang compiles. If you need Clang for some other reason, such as a specific plugin, look into using Clang/LLVM for Windows.

>> Hope this helps,
>> Andrew
Comment 8 patrikhuber 2018-04-28 13:27:31 UTC
Sorry, the quoting got really messed up. And I don't think comments can be edited here, or can they?
Comment 9 Gael Guennebaud 2018-06-08 14:28:37 UTC
ok, let's close it.
Comment 10 Nobody 2019-12-04 15:13:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

Note You need to log in before you can comment on or make changes to this bug.