Bug in latest compiler 2011.11.344 (exhibits Access Violation in boost::thread) (Windows, 32-bit)

[jorgensen]

I downloaded the latest version of the compiler to evaluate it with our existing code base. The bug will manifest with this minimal program built with boost 1.47.0 (yes, I know that there's a newer version of boost). The compiler was integrated with Visual Studio 2010.

#include <boost/thread/thread.hpp>void thread_main();int main(){ boost::thread* tp = new boost::thread(thread_main); tp->join();}void thread_main(){}

Specifically what happens is that the address to thread_main is dereferenced to yield the first four bytes of the actual function. This value gets stored in the pimpl class for Windows as the thread function pointer. Then when the function is actually started up you get an Access Violation.Yes I also know that the above code should be passing &thread_main, not just thread_main. And in fact if you pass &thread_main the code works as expected. But the above code exhibits no warning from the compiler and naturally when you look at the assembly emitted thread_main yields the same thing as &thread_main: the address of the function. Thus I believe this is a bug.For completeness I'll note that the above code works fine with MSVC 10.

[Georg_Z_Intel]

Hello,

this is indeed a bug. The compiler does not seem to interpret the cast "static_cast(...)" correctly and hence the entry point to "thread_main" is incorrect in the end.

I've filed a defect ticket (DPD200235181) and let you know about the status.

There are two workarounds I'm aware of:

1. Use "boost::thread* tp = new boost::thread(boost::bind(thread_main));"
2. In the configuration of BOOST define BOOST_NO_RVALUE_REFERENCES (not recommended as it impacts performance)

Thank you for reporting this!

Best regards,

Georg Zitzlsberger

[Georg_Z_Intel]

Hello, this problem will be fixed with Intel(R) Composer XE 2011 Update 12 that's going to be released soon. Best regards, Georg Zitzlsberger