| Summary: | ICE with VS2015 Update 1 and /openmp | ||
|---|---|---|---|
| Product: | Eigen | Reporter: | patrikhuber |
| Component: | General | Assignee: | Nobody <eigen.nobody> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Compilation Problem | CC: | chtz, gael.guennebaud, jacob.benoit.1 |
| Priority: | Normal | ||
| Version: | 3.3 (current stable) | ||
| Hardware: | All | ||
| OS: | Windows | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 558 | ||
The only way to find a workaround (if any) would be to try to comment some code in Eigen (within general_matrix_matrix_product::run are within the callee) to find what really confuse MSVC... I'm definitely not going to do so, but if you find a concrete line of code, I can probably help in suggesting workarounds. Also, it seems to be exactly the same as bug 1096. Yep, that bug looks the same. Though its title sucks a bit, it's not "CTP1" - what he meant was probably "VS2015 Update 1 CTP", which came out in October. My bug is related to Update 1 RTM (the "final") that came out a couple of days ago. Sadly, it seems to have the same bug. Also my code is a lot shorter and isolates the bug better. I'll try to experiment a bit more if I can find some time. Would also be nice if at least one other person could confirm the same behaviour. Had a quick try: If I remove the #pragma omp atomic from GeneralMatrixMatrix.h line 151, the ICE disappears. I can confirm the offending code is in that section.
#pragma omp critical
{
for(Index i=0; i<threads; ++i)
#pragma omp atomic
--(info[i].users);
}
If I remove the #pragma omp atomic, the code compiles. (but probably won't do what it's intended to do anymore.
Also if I change
--(info[i].users);
to something silly like "++i;", the code also compiles.
It thus seems to depend on the #pragma omp atomic and what is actually inside the section too.
Does the following work?
{
int& users = info[i].users;
#pragma omp atomic
--users;
}
@Christoph: No, it gives a Error C2440 'initializing': cannot convert from 'volatile int' to 'int &' If I change it to volatile int& users = info[i].users; (or even "auto& users = ..."), I get the ICE again. (In reply to patrikhuber from comment #6) > Error C2440 'initializing': cannot convert from 'volatile int' to 'int &' Sorry, of course it has to be `volatile int`. But apparently, that did not help. I don't see any other obvious work-around, at the moment. Okay, thank you! Here's the link to the connect bug: https://connect.microsoft.com/VisualStudio/feedback/details/2081014/internal-compiler-error-when-compiling-eigen-with-openmp I tried to update it with this new information, but it wouldn't let me add comments... Does the workaround suggested in Bug 1096 comment 4 work for you? Yep, this makes the ICE go away and it compiles! *** This bug has been marked as a duplicate of bug 1096 *** -- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com'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: https://gitlab.com/libeigen/eigen/issues/1125. |
The following code causes an internal compiler error in VS2015 Update 1 when compiling with /openmp... #include "Eigen/Core" int main(int argc, char *argv[]) { Eigen::MatrixXf A_Eigen; Eigen::MatrixXf AtA_Eigen = A_Eigen.transpose() * A_Eigen; return EXIT_SUCCESS; } 1>------ Build started: Project: rcr-detect, Configuration: Debug x64 ------ 1> test.cpp 1>c:\eigen-3.3-alpha1\eigen\src\core\products\generalmatrixmatrix.h(66): fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1> Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information Error occurs both in Release and Debug mode. It compiled fine in VS2015 (before Update 1). Also the error goes away if I remove /openmp. I'll file a bug in MS Connect too, but is there anything we can do as a workaround?