Intel C++ 16 and boost 1.59 compilation error

[Scott_S-S_]

Hi

I'm getting a compile error using intel C++ 15.04 and 16.0 on linux 64. Note I do not get the same errors building on a windows platform:

/.../distro/boost_1_59_0/boost/thread/detail/nullary_function.hpp(184): error: more than one instance of constructor "boost::detail::nullary_function<R ()>::impl_type<F>::impl_type [with R=size_t={unsigned long}, F=boost::thread_detail::default_barrier_reseter]" matches the argument list:
            function "boost::detail::nullary_function<R ()>::impl_type<F>::impl_type(boost::detail::thread_move_t<F>) [with R=size_t={unsigned long}, F=boost::thread_detail::default_barrier_reseter]"
            function "boost::detail::nullary_function<R ()>::impl_type<F>::impl_type(const boost::detail::nullary_function<size_t={unsigned long} ()>::impl_type<boost::thread_detail::default_barrier_reseter> &) [with R=size_t={unsigned long}, F=boost::thread_detail::default_barrier_reseter]"
            argument types are: (boost::thread_detail::default_barrier_reseter)
        impl(new impl_type<typename decay<F>::type>(thread_detail::decay_copy(boost::forward<F>(f))))
                                                   ^
          detected during instantiation of "boost::detail::nullary_function<R ()>::nullary_function(boost::detail::thread_move_t<F>) [with R=size_t={unsigned long}, F=boost::thread_detail::default_barrier_reseter]" at line 139 of "/opt/app/caf/builds/smitaau/lib//distro/boost_1_59_0/boost/thread/barrier.hpp"

/.../boost_1_59_0/boost/thread/detail/nullary_function.hpp(184): error: more than one instance of constructor "boost::detail::nullary_function<R ()>::impl_type<F>::impl_type [with R=size_t={unsigned long}, F=boost::thread_detail::void_fct_ptr_barrier_reseter]" matches the argument list:
            function "boost::detail::nullary_function<R ()>::impl_type<F>::impl_type(boost::detail::thread_move_t<F>) [with R=size_t={unsigned long}, F=boost::thread_detail::void_fct_ptr_barrier_reseter]"
            function "boost::detail::nullary_function<R ()>::impl_type<F>::impl_type(const boost::detail::nullary_function<size_t={unsigned long} ()>::impl_type<boost::thread_detail::void_fct_ptr_barrier_reseter> &) [with R=size_t={unsigned long}, F=boost::thread_detail::void_fct_ptr_barrier_reseter]"
            argument types are: (boost::thread_detail::void_fct_ptr_barrier_reseter)
        impl(new impl_type<typename decay<F>::type>(thread_detail::decay_copy(boost::forward<F>(f))))
                                                   ^
          detected during instantiation of "boost::detail::nullary_function<R ()>::nullary_function(boost::detail::thread_move_t<F>) [with R=size_t={unsigned long}, F=boost::thread_detail::void_fct_ptr_barrier_reseter]" at line 204 of "/opt/app/caf/builds/smitaau/lib//distro/boost_1_59_0/boost/thread/barrier.hpp"

/

Here's a small standalone example that replicates the issue:

#include <boost/thread.hpp>
#include <tr1/memory>

template <typename T>
class ThreadLocalData
{
private:
  /// all local storage for this type
  static boost::thread_specific_ptr<T> &instance() {
    static boost::thread_specific_ptr<T> sTLS;
    return sTLS;
  }

public:
  /// get an instance of thread local storage
  static T& getThreadLocalInstance()
  {
    T* pT = instance().get();
    if (!pT)
    {
      pT = new T;
      instance().reset(pT);
    }
    return *pT;
  }

  /// Destroy the current instance of threadlocal data by resetting it.
  static void destroy()
  {
    instance().reset();
  }

};

namespace {

class ThreadData
{
public:
  ThreadData() : myValue()
  {
    myValue.reset(new int(1));
  }
  std::tr1::shared_ptr<int> getValue() const { return myValue; }

  ~ThreadData() { }

private:
  std::tr1::shared_ptr<int> myValue;
};

}
int& get()
{
  return *ThreadLocalData<ThreadData>::getThreadLocalInstance().getValue();
}

int main()
{
  return get();
}

Compile this with

$ icpc -I <path_to_boost_1_59> -fpermissive test.cpp

and you should see the error. But is you remove the -fpermissive arg then the error goes away. This is strange, since I would expect this flag actually make the compiler more forgiving rather than less forgiving,

Any ideas?

Thanks

[Melanie_B_Intel]

I can see this also. I opened DPD200376337 to track the problem. Thank you for reporting it. 

--Melanie

[Kittur_G_Intel]

Melanie, I've added the defect number to this issue so I can let Scott know on this thread when the release with a fix is out, thanks.

_Kittur

[Kittur_G_Intel]

Hi Scott,
Just letting you know that this issue is fixed in the latest 16.0 update 2 release which you can download and test it out. Thanks for bringing this issue to our attention and patience through this issue as well.
Kittur