Sat, 02/29/2020 - 21:06
We are having problems building OCC 7.4, using C runtime 142 on Visual Studio 2019 16.4.4,
In Release Win32 mode, we can build Foundation.sln, ModelingData.sln, but when we try to build ModelingAlgorithms.sln the compiler gets to BRepExtrema_DistShapeShape.cxx and seems to be in an infinite loop.
The c++ compiler is locked on 29% CPU usage ad-infinitum.
Anyone else seen this, we can reproduce the problem on several machines and on our CI build
Just for clarity this is not specific to OCC 7.4 we have the same problem with OCC 7.3
The line that causes the hang is Line 136
std::stable_sort(aPairList.begin(), aPairList.end(), BRepExtrema_CheckPair_Comparator);
Comment this out or change to std::sort and it compiles, I am not knowledgable enough on this function to know we need stable_sort?
Sat, 02/29/2020 - 21:07
Just for clarity this is not specific to 7.4 OCC we have the same problem with OCC 7.3
Sun, 03/01/2020 - 12:13
I have reported this problem to Microsoft https://developercommunity.visualstudio.com/content/problem/934955/stdstable-sort-causes-the-compiler-to-hang.html it is clearly not an issue with OCC as the source compiles fine on previous versions of Visual Studio
Thu, 04/30/2020 - 09:09
The point is closed at MS. Still the same problem with newest VS2019.
Any workaround known?
Sat, 05/02/2020 - 16:22
They have closed issue not because it is not reproducable, but because they have not recieved minimized reproducing sample (and they are too busy building external open source projects).
So that extracting sample code would help revealing bug report.
Tue, 05/12/2020 - 11:04
This workaround is working now for me also, thankyou.
Update: well it got further, now hung on:
...
24> Creating library ..\..\..\win32\vc14\lib\TKSTEP.lib and object ..\..\..\win32\vc14\lib\TKSTEP.exp
24>TKSTEP.vcxproj -> C:\_SVN\OpenCascade\opencascade-7.4.0\adm\msvc\vc142\.\..\..\..\win32\vc14\bin\TKSTEP.dll
Fri, 05/01/2020 - 13:06
There is a workaround but I don't know how safe it is.
if you change a couple of instances where this is in the code
std::stable_sort(aPairList.begin(), aPairList.end(), BRepExtrema_CheckPair_Comparator);
to use std::sort, as in my original mail, then it will compile , can someone advise if stable_sort is essential
Fri, 05/01/2020 - 13:06
You can also downgrade the Platform Toolset to v141 and this fixes it
Sat, 05/02/2020 - 16:08
If I understanda correctly, the problem affects only 32-bit builds, and not 64-bit builds, which indicates that Microsoft abondance 32-bit support in their building toolchains.
Why using 32-bit targets in '2020 anyway?
Sat, 05/02/2020 - 16:15
Its possible, I suspect if I had time to make a small enough test case for them, they would have found the problem, but it seems it is not a simple problem, it relates to the state of the compiler as some stable_sorts work.
We use 32 bit for 2 reasons, compatibility with other tool chains and memory use on large problems
Tue, 05/12/2020 - 08:37
A similar issue. MSVC 2019 toolset 142 32 bit hangs for me building TKTopAlgo:
...
8>BRepApprox_TheComputeLineBezierOfApprox_0.cxx
8>BRepApprox_TheComputeLineOfApprox_0.cxx
8>BRepApprox_TheFunctionOfTheInt2SOfThePrmPrmSvSurfacesOfApprox_0.cxx
8>BRepApprox_TheImpPrmSvSurfacesOfApprox_0.cxx
8>BRepApprox_TheInt2SOfThePrmPrmSvSurfacesOfApprox_0.cxx
8>BRepApprox_TheMultiLineOfApprox_0.cxx
8>BRepApprox_ThePrmPrmSvSurfacesOfApprox_0.cxx
8>BRepApprox_TheZerImpFuncOfTheImpPrmSvSurfacesOfApprox_0.cxx
Been sitting on this for a couple of hours now. will leave it a couple more but I'm not hopeful much will happen!
yes builds OK in x64. We need 32bit support for our customer base, still a few out there...
Thu, 06/25/2020 - 11:17
MSFT has confirmed the bug in compiler and suggested one more workaround (disabling inlining locally):
https://developercommunity.visualstudio.com/content/problem/1082623/infinite-compilation-using-stdstable-sort.html?childToView=1091245#comment-1091245
Mon, 08/03/2020 - 12:44
I can confirm that if you disable inline function expansion for the win32 build then VS2019 will compile OK, I have not managed to locate which specific local function to apply no-inline to.
I also have no idea yet if this effects performance , these are the specific functions that are problematic
I have tried various no-inlining options on the iterator as suggested by microsoft with no luck
Tue, 08/04/2020 - 22:55
For me the compiler hang was fixed after I declared "__declspec(noinline)" the function
typename NCollection_StlIterator::difference_type operator- (const NCollection_StlIterator& theOther) const
in source file NCollection_StlIterator.hxx.
Thu, 08/06/2020 - 17:57
It seems that with Visual Studio 2019 Version 16.7.0 this bug is fixed.
Tue, 08/11/2020 - 00:46
Maett's identification of changing this method below 100% fixes the compilation issues, but for me the latest version of visual studio still hangs on compilation without this fix
//! Difference
__declspec(noinline) typename NCollection_StlIterator::difference_type operator- (const NCollection_StlIterator& theOther) const
{
Standard_STATIC_ASSERT((opencascade::std::is_same<std::random_access_iterator_tag,Category>::value));
return myIterator.Differ (theOther.myIterator);
}
Mon, 11/09/2020 - 14:15
OCCT 7.5.0 includes a workaround for this VS2019 bug - you can try upgrading OCCT.