Re: [Threads-devel] Intel compiler issue and boost::thread

Subject: Re: [Threads-devel] Intel compiler issue and boost::thread
From: Anthony Williams (anthony_at_[hidden])
Date: 2012-08-06 11:38:39

On 06/08/12 16:14, Andy Schneider wrote:
> We have some code that looks like this:
> 
> void
> fileProcessorFunction ()
> {
>        // … some implementation …
> }
> 
> Later we do:
> 
> new boost::thread(fileProcessorFunction);
> 
> We found, using Intel C++ compiler v12 on Windows with boost 1.47 that
> our application crashed in both Debug and Release.
> 
> This constructor ends up initializing thread_info with the result of
> make_thread_info thus:
> 
> template <class F>
> thread(F&& f) :
>   thread_info(make_thread_info(static_cast<F&&>(f)))
> {
>     start_thread()
> }
> 
> which maps into assembly that takes f and then dereferences it and
> passes it to make_thread_info so the thread_data member ends up having
> not the function pointer f that it should have but instead a pointer
> equal to the first 4 bytes of what f was pointing at. Things go downhill
> from there.
> 
> We noticed that removing the static_cast (as below) resolved this issue.

> Clearly there’s a compiler defect at play but I was wondering why the
> static_cast <F&&> in the first place? Does this result in a valuable
> optimization that’s subverted by removing it?

The static cast to F&& is necessary to allow passing move-only function
objects to this constructor. It is equivalent to std::forward<F>(f), and
does "perfect forwarding" --- rvalues are passed as rvalue references,
lvalues as lvalue references

Anthony
-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976