Intel compiler 11 with boost 1.40.0 shared_ptr problem.

[cppxyz]

the code is simple, as listed below

#include
#include
#include

int main()
{
std::string line;
boost::regex pattern("^Subject:(Re: |Aw: )*(.*)");

while(std::cin)
{
std::getline(std::cin,line);
boost::smatch matches;
if(boost::regex_match(line,matches,pattern))
std::cout< }
}

the compiling is fine without problem, but every time i ran this prgram, i got something like

Assertion failed: px != 0, file C:\boost_1_40_0\boost/smart_ptr/shared_ptr.hpp,
line 412

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


If i add debug option like /MDd or /MTd, everything is fine.


but compiling by using VS2008 cl is without any problem with or without debug option.

could any one give some help here please?

[Mark_S_Intel1]

Thanks for the problem report and the test case. We will look into this issue and get back to you.
What version of the compiler are you using (e.g. what's the output of icl.exe )?

--mark

[cppxyz]

Quoting - Mark Sabahi (Intel)

Thanks for the problem report and the test case. We will look into this issue and get back to you.
What version of the compiler are you using (e.g. what's the output of icl.exe )?

--mark

D:cpp>icl boost.ex2.cpp /IC:boost_1_40_0 /link /LIBPATH:C:boost_1_40_0stage
lib
Intel C++ Compiler Professional for applications running on IA-32, Version 11
.1 Build 20090930 Package ID: w_cproc_p_11.1.048
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

boost.ex2.cpp
Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:boost.ex2.exe
/LIBPATH:C:boost_1_40_0stagelib
boost.ex2.obj

[Mark_S_Intel1 · Accepted solution]

I was able to reproduce the problem, and have a solution. When building using the Intel compiler, the macro -D_SECURE_SCL is defined to 0. When building with the Microsoft compiler, this is not specified, and defaults to a value of 1. From what I see, this is what is largely contributing to the difference in the run-time behavior between the icl and cl generated codes. The macro was defined differently in the config file to disable Microsoft "secure" overloads in Dinkumware* libraries since they caused compile errors with Intel compiler versions 9 and 10. This is no longer an issue starting with Intel compiler version 11.0 and higher. The fix is to modify the jam file (in my boost installation: toolsbuildv2toolsintel-win.jam) to change the definition to _SECURE_SCL=1 and rebuild the Boost libraries like:

C:boost_1_40_0>bjam --build-dir=c:boost_1_40_0 toolset=intel --build-type=complete stage

I confirmed that your test case ran correctly with the above solution.

The Intel Compiler team has requested the Boost team to change the definition of the macro (which was added to work around the Intel 9 and 10 compiler versions of a partial template ordering problem).

Please let us know if this solution resolves the problem.

Thanks,
--mark

[cppxyz]

Quoting - Mark Sabahi (Intel)

I was able to reproduce the problem, and have a solution. When building using the Intel compiler, the macro -D_SECURE_SCL is defined to 0. When building with the Microsoft compiler, this is not specified, and defaults to a value of 1. From what I see, this is what is largely contributing to the difference in the run-time behavior between the icl and cl generated codes. The macro was defined differently in the config file to disable Microsoft "secure" overloads in Dinkumware* libraries since they caused compile errors with Intel compiler versions 9 and 10. This is no longer an issue starting with Intel compiler version 11.0 and higher. The fix is to modify the jam file (in my boost installation: toolsbuildv2toolsintel-win.jam) to change the definition to _SECURE_SCL=1 and rebuild the Boost libraries like:

C:boost_1_40_0>bjam --build-dir=c:boost_1_40_0 toolset=intel --build-type=complete stage

I confirmed that your test case ran correctly with the above solution.

The Intel Compiler team has requested the Boost team to change the definition of the macro (which was added to work around the Intel 9 and 10 compiler versions of a partial template ordering problem).

Please let us know if this solution resolves the problem.

Thanks,
--mark

Excellent, it works.

worth the lengthy recompiling.

THANKS A LOT!

[Mark_S_Intel1]

I created a summary of theissue reported here and in other threads at http://software.intel.com/en-us/articles/using-boost-libraries-with-intelr-c-compilers-11x-for-windows/ .

--mark