issue using std::thread and std::ref via icpc

issue using std::thread and std::ref via icpc

Hi guys,

there seems to be an issue using std::ref and std:: thread with icpc, even if you use the tbb/thread/compat.h header:

There are no compilation issues on clang++. I am not using the SP1 beta of composer yet, so I am not sure if these issues have been fixed.

I have found the main issue is that std::ref cannot be used with std::thread (when using icpc). I am getting a lot of the following errors:

aProgram.c(747): error: namespace "std" has no member "thread"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(iarg6),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

aProgram.c(747): error: namespace "std" has no member "ref"
threads[j] = std::thread(func1,std::ref(arg1),std::ref(arg2),std::ref(arg3),std::ref(arg4),std::ref(local_eigs),eta,std::ref(arg6),std::ref(arg7),std::ref(arg8),arg9,arg10,start,end,,std::ref(aMutex));
^

Unfortunately, I cannot give you guys the program to debug this, but I am certain this is not an issue with the code as it runs without issue using clang++. 

Clang++ is too effin slow for what I'm doing, and so icpc/icc are the only way the program will be fast enough (to my standards), even though it is parallelized extensively.

note: please don't worry about some weird syntax, as I had to edit the filename/parameters to ensure privacy of my program. The key is that the errors are related to both std::ref and std:;thread...

can someone tell me if this has been fixed?

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington
33 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

As icpc depends on g++ for definition of these things, you need an active g++ installation new enough to support these facilities under -std=c++11, and you must give icpc that option.  icpc would probably not support any facilities not present in g++ 4.7.  If you would give a test case, someone might be able to comment.

As a very quick verification take a look if there is a thread header file in Include folder.

in the /opt/intel/include or /opt/intel/mkl/include there is no such header, here is the compiler command:

icpc -g -std=c++11 -stdlib=libc++ -O4 -o aProgram aProgram.c -I/usr/local/include -I/opt/intel/composerxe/mkl/include -I/usr/local/include -I/opt/local/include -I/usr/include -L/usr/local/fsl/lib -lfslio -L/usr/local/lib -lniftiio -L/usr/lib -L/usr/local/lib -L/opt/intel/composerxe/mkl/lib -liomp5 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lznz -lm -lz
icpc: command line warning #10159: invalid argument for option '-std'
icpc: command line warning #10006: ignoring unknown option '-O4'
aProgram.c(161): error: namespace "std" has no member "ref"

 

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

What version of the intel compiler are you using?  Your version does not seem to recognize c++11 as a valid standard.  Try either upgrading your compiler version (13.1.3 20130607 recognizes c++11) or try using -std=c++0x instead.

I'm using 13.0.3 (gcc version 4.2.1 compatibility), but this is weird because I just installed the composerxe for C++ less than a month ago. I know that by default OSX has gcc 4.2.1 and maybe this is why? How can I fix this issue?

I've tried using prebuilt binaries of newer gcc/g++ but I do not like them because they are compiled without many useful flags. 

Does the installer automatically install an older ICPC if it detects an older gcc/g++?? Any help in dealing with this issue would be great.

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

You can grab newer versions of the intel compiler from the registrationcenter.intel.com website to install.  For the full c++11 featureset I think you'll need a newer version of gcc.  I don't have the intel compilers on mac so I cannot test there, but I do know that I build gcc/g++ locally on my mac from the macports (http://www.macports.org/) repository.  Through ports you can get gcc/g++ versions 4.7.3, 4.8.1 and nightly versions of 4.9.x among others.

>>...Try either upgrading your compiler version (13.1.3 20130607 recognizes c++11) or try using -std=c++0x instead.

Simply to let you know that after some update both options do the same, that is -std=c++0x and -std=c++11. The best way to verify is to use -help option.

The Intel compiler isn't standalone, it uses host's definition of <stdio.h> etc. gcc 4.2 doesn't provide <thread>. You could try adding the option -use-clang-env to the compile and link steps, this will tell the Intel compiler to use the clang include files and runtime libraries.

just tried that Melanie, same error.

It seems like icpc does not like the way I am using c++11's thread to call functions with multiple references.

The weird thing is that I think the 13.1.3 update might fix it because after taking Sergey's advice and doing the --help thing on ICPC, I saw:

Arguments:

val Specifies the specific language standard to conform to. Possible values are:

c89 Conforms to the ISO/IEC 9899:1990 International Standard. This value is only available on Linux* OS and OS X*.

c99 Conforms to The ISO/IEC 9899:1999 International Standard.

c9x This value is equivalent to specifying value c99. This value is only available on Linux* OS and OS X*.

gnu89 Conforms to ISO C90 plus GNU* extensions. This value is only available on Linux* OS and OS X*.

gnu99 Conforms to ISO C99 plus GNU* extensions. This value is only available on Linux* OS and OS X*.

gnu++98 Conforms to the 1998 ISO C++ standard plus GNU extensions. This value is only available on Linux* OS and OS X*.

c++0x Enables support for the following C++11 (formerly known as C++0x) features:

o Atomic types and operations

o Scoped enumeration types

o Defaulted and deleted functions

o Rvalue references

o Empty macro arguments

o Variadic macros

o Type long long

o Trailing comma in enum definition

o Concatenation of mixed-width string literals

o Extended friend declarations

o Use of ">>" to close two template argument lists

o Relaxed rules for use of "typename"

o Relaxed rules for disambiguation using the "template" keyword

o "extern template" to suppress instantiation of an entity

o "auto" type specifier

o decltype operator

o static_assert

o compliant __func__

o lambda expressions

o character types char16_t and char32_t to store UTF-16 and UTF-32 encoding values, respectively

o template aliases

o variadic templates

o nullptr

o late-specified return types as defined in gcc proposal N2541

o default template arguments for function templates

o standard attributes as defined in gcc proposal N2761

o new style SFINAE as defined in gcc proposal N2634

o noexcept

o explicit conversion functions (N2437)

o general initializer lists (partial)

o generalized constant expressions (partial)

o use of "this" in late-specified return types (N3282)

o range based for loops

gnu++0x This value is equivalent to specifying value c++0x. This value is only available on Linux* OS and OS X*.

So I think the icpc version I am using is not fully supporting C++11, is that part of the problem? Seems so, as the other C++11 features would be useless in my specific case. I am using C++11 standard for one reason only: the threading library.

all of my data structures and whatnot are C standard. same with memory allocation.

on that note, I have a quick question regarding memory allocation when using MKL. I use calloc for all allocations. I also make it a habit to declare/allocate via calloc once, and then if I use this structure in a loop, I just bzero it at the beginning. I felt this way would remove wasteful allocation/deallocations, and instead allow me to have one "chunk" that each thread can allocate at the beginning of the function, followed by clearing/using it in the loop, and then freeing at the end of the threaded function.

I saw this option in icpc: 

-inline-calloc
directs the compiler to inline calloc() calls as malloc()/memset()

Such a directive suggests that calloc might be slower than a malloc memset. Is this the case? I never imagined that malloc would be better for what I'm doing (large scale linear algebra, each thread is looping approximately 2000 times where each loop involves getting eigs/svd/pinv of matrices that are no smaller than 100x100).

any help or advice would be great on how to use ICPC with C++11 threads. The composer XE version I am using came with 13.0.3 by default. 

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

just tried that Melanie, same error.

It seems like icpc does not like the way I am using c++11's thread to call functions with multiple references.

The weird thing is that I think the 13.1.3 update might fix it because after taking Sergey's advice and doing the --help thing on ICPC, I saw:

Arguments:

val Specifies the specific language standard to conform to. Possible values are:

c89 Conforms to the ISO/IEC 9899:1990 International Standard. This value is only available on Linux* OS and OS X*.

c99 Conforms to The ISO/IEC 9899:1999 International Standard.

c9x This value is equivalent to specifying value c99. This value is only available on Linux* OS and OS X*.

gnu89 Conforms to ISO C90 plus GNU* extensions. This value is only available on Linux* OS and OS X*.

gnu99 Conforms to ISO C99 plus GNU* extensions. This value is only available on Linux* OS and OS X*.

gnu++98 Conforms to the 1998 ISO C++ standard plus GNU extensions. This value is only available on Linux* OS and OS X*.

c++0x Enables support for the following C++11 (formerly known as C++0x) features:

o Atomic types and operations

o Scoped enumeration types

o Defaulted and deleted functions

o Rvalue references

o Empty macro arguments

o Variadic macros

o Type long long

o Trailing comma in enum definition

o Concatenation of mixed-width string literals

o Extended friend declarations

o Use of ">>" to close two template argument lists

o Relaxed rules for use of "typename"

o Relaxed rules for disambiguation using the "template" keyword

o "extern template" to suppress instantiation of an entity

o "auto" type specifier

o decltype operator

o static_assert

o compliant __func__

o lambda expressions

o character types char16_t and char32_t to store UTF-16 and UTF-32 encoding values, respectively

o template aliases

o variadic templates

o nullptr

o late-specified return types as defined in gcc proposal N2541

o default template arguments for function templates

o standard attributes as defined in gcc proposal N2761

o new style SFINAE as defined in gcc proposal N2634

o noexcept

o explicit conversion functions (N2437)

o general initializer lists (partial)

o generalized constant expressions (partial)

o use of "this" in late-specified return types (N3282)

o range based for loops

gnu++0x This value is equivalent to specifying value c++0x. This value is only available on Linux* OS and OS X*.

So I think the icpc version I am using is not fully supporting C++11, is that part of the problem? Seems so, as the other C++11 features would be useless in my specific case. I am using C++11 standard for one reason only: the threading library.

all of my data structures and whatnot are C standard. same with memory allocation.

on that note, I have a quick question regarding memory allocation when using MKL. I use calloc for all allocations. I also make it a habit to declare/allocate via calloc once, and then if I use this structure in a loop, I just bzero it at the beginning. I felt this way would remove wasteful allocation/deallocations, and instead allow me to have one "chunk" that each thread can allocate at the beginning of the function, followed by clearing/using it in the loop, and then freeing at the end of the threaded function.

I saw this option in icpc: 

-inline-calloc
directs the compiler to inline calloc() calls as malloc()/memset()

Such a directive suggests that calloc might be slower than a malloc memset. Is this the case? I never imagined that malloc would be better for what I'm doing (large scale linear algebra, each thread is looping approximately 2000 times where each loop involves getting eigs/svd/pinv of matrices that are no smaller than 100x100).

any help or advice would be great on how to use ICPC with C++11 threads. The composer XE version I am using came with 13.0.3 by default. 

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

>>>>aProgram.c(747): error: namespace "std" has no member "thread"
>>>>...
>>>>aProgram.c(747): error: namespace "std" has no member "ref"
>>...

I'd like to refer to one of your previous statements:

>>...
>>in the /opt/intel/include or /opt/intel/mkl/include there is no such header...
>>...

The thread header needs to be in a regular Non-Intel Include directory of GCC compiler.

Can you provide preprocessed test case, or even better a small test case which shows the problem. You can open a support ticket at premier.intel.com, and it can be treated confidentially. (The -E switch produces preprocessed source file). I'm not familiar with the inlin-calloc option but reading the documentation page, it says that it may inline the bzero in certain circumstances. There's a separate support forum for MKL.

>>...Such a directive suggests that calloc might be slower than a malloc memset. Is this the case?

You could actually verify it in two tests, like:

[ Test Case 1 ]
...
// Timer start -> T1
...
for( int i = 0; i < 2048; i++ )
{
piDataC[i] = ( int * )calloc( 1, sizeof( int ) * 1024 );
}
...
// Timer end -> T2
iDeltaC = T2 - T1
...

[ Test Case 2 ]
...
// Timer start -> T1
...
for( int i = 0; i < 2048; i++ )
{
piDataM[i] = ( int * )malloc( sizeof( int ) * 1024 );
memset( piDataM[i], 0x0, sizeof( int ) * 1024 );
}
...
// Timer end -> T2
iDeltaM = T2 - T1
...

and compare execution times iDeltaC and iDeltaM.

Hi Sergey,

I see what you're saying. However my question would be: If I can change the compiler from icpc to clang++, and the #include <thread> directive issue goes away with the latter, how isn't the thread header in the appropriate /include directory?

I did a "locate" for thread and found that the one being used by clang++ likely resides in:

/usr/local/include/c++/4.8.0/thread

I tried including this path manually (-I /usr/local/include/c++/4.8.0) with #include <thread> on icpc, but I get a lot of errors suggesting I'm doing it wrong (heh):

/usr/local/include/c++/4.8.0/bits/stl_relops.h(72): error #77: this declaration has no storage class or type specifier
_GLIBCXX_BEGIN_NAMESPACE_VERSION
^

/usr/local/include/c++/4.8.0/bits/stl_relops.h(86): error: expected a ";"
template <class _Tp>
^

/usr/local/include/c++/4.8.0/bits/stl_relops.h(131): warning #12: parsing restarts here after previous syntax error
} // namespace rel_ops
^

/usr/local/include/c++/4.8.0/bits/move.h(38): error #77: this declaration has no storage class or type specifier
_GLIBCXX_BEGIN_NAMESPACE_VERSION
^

/usr/local/include/c++/4.8.0/bits/move.h(45): error: expected a ";"
template<typename _Tp>
^

/usr/local/include/c++/4.8.0/bits/move.h(54): warning #12: parsing restarts here after previous syntax error
} // namespace
^

/usr/local/include/c++/4.8.0/type_traits(43): error: variable "std::_GLIBCXX_BEGIN_NAMESPACE_VERSION" has already been defined
_GLIBCXX_BEGIN_NAMESPACE_VERSION
^

/usr/local/include/c++/4.8.0/type_traits(57): error: expected a ";"
template<typename _Tp, _Tp __v>
^

/usr/local/include/c++/4.8.0/type_traits(67): error: integral_constant is not a template
typedef integral_constant<bool, true> true_type;
^

/usr/local/include/c++/4.8.0/type_traits(70): error: integral_constant is not a template
typedef integral_constant<bool, false> false_type;
^

/usr/local/include/c++/4.8.0/type_traits(73): error: integral_constant is not a template
constexpr _Tp integral_constant<_Tp, __v>::value;
^

/usr/local/include/c++/4.8.0/type_traits(85): error: not a class or struct name
: public false_type
^

/usr/local/include/c++/4.8.0/type_traits(108): error: not a class or struct name
: public true_type
^

/usr/local/include/c++/4.8.0/type_traits(128): error: integral_constant is not a template
: public integral_constant<bool, !_Pp::value>
^

/usr/local/include/c++/4.8.0/type_traits(128): error: not a class or struct name
: public integral_constant<bool, !_Pp::value>
^

/usr/local/include/c++/4.8.0/type_traits(144): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(148): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(153): error: integral_constant is not a template
: public integral_constant<bool, (__is_void_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(153): error: not a class or struct name
: public integral_constant<bool, (__is_void_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(159): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(163): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(167): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(171): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(175): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(180): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(185): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(189): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(193): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(197): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(201): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(205): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(209): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(213): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(217): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(221): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(236): error: integral_constant is not a template
: public integral_constant<bool, (__is_integral_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(236): error: not a class or struct name
: public integral_constant<bool, (__is_integral_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(242): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(246): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(250): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(254): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(265): error: integral_constant is not a template
: public integral_constant<bool, (__is_floating_point_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(265): error: not a class or struct name
: public integral_constant<bool, (__is_floating_point_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(272): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(274): error: namespace "std" has no member "size_t"
template<typename _Tp, std::size_t _Size>
^

/usr/local/include/c++/4.8.0/type_traits(280): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(284): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(288): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(293): error: integral_constant is not a template
: public integral_constant<bool, (__is_pointer_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(293): error: not a class or struct name
: public integral_constant<bool, (__is_pointer_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(300): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(304): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(309): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(313): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(320): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(324): error: integral_constant is not a template
: public integral_constant<bool, !is_function<_Tp>::value> { };
^

/usr/local/include/c++/4.8.0/type_traits(324): error: not a class or struct name
: public integral_constant<bool, !is_function<_Tp>::value> { };
^

/usr/local/include/c++/4.8.0/type_traits(329): error: integral_constant is not a template
: public integral_constant<bool, (__is_member_object_pointer_helper<
^

/usr/local/include/c++/4.8.0/type_traits(329): error: not a class or struct name
: public integral_constant<bool, (__is_member_object_pointer_helper<
^

/usr/local/include/c++/4.8.0/type_traits(335): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(339): error: integral_constant is not a template
: public integral_constant<bool, is_function<_Tp>::value> { };
^

/usr/local/include/c++/4.8.0/type_traits(339): error: not a class or struct name
: public integral_constant<bool, is_function<_Tp>::value> { };
^

/usr/local/include/c++/4.8.0/type_traits(344): error: integral_constant is not a template
: public integral_constant<bool, (__is_member_function_pointer_helper<
^

/usr/local/include/c++/4.8.0/type_traits(344): error: not a class or struct name
: public integral_constant<bool, (__is_member_function_pointer_helper<
^

/usr/local/include/c++/4.8.0/type_traits(351): error: integral_constant is not a template
: public integral_constant<bool, __is_enum(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(351): error: identifier "__is_enum" is undefined
: public integral_constant<bool, __is_enum(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(351): error: type name is not allowed
: public integral_constant<bool, __is_enum(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(351): error: not a class or struct name
: public integral_constant<bool, __is_enum(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(357): error: integral_constant is not a template
: public integral_constant<bool, __is_union(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(357): error: identifier "__is_union" is undefined
: public integral_constant<bool, __is_union(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(357): error: type name is not allowed
: public integral_constant<bool, __is_union(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(357): error: not a class or struct name
: public integral_constant<bool, __is_union(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(363): error: integral_constant is not a template
: public integral_constant<bool, __is_class(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(363): error: identifier "__is_class" is undefined
: public integral_constant<bool, __is_class(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(363): error: type name is not allowed
: public integral_constant<bool, __is_class(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(363): error: not a class or struct name
: public integral_constant<bool, __is_class(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(369): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(373): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(377): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(381): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(385): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(389): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(393): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(397): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(401): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(405): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(408): error: namespace "std" has no member "nullptr_t"
struct __is_nullptr_t_helper<std::nullptr_t>
^

/usr/local/include/c++/4.8.0/type_traits(409): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(414): error: integral_constant is not a template
: public integral_constant<bool, (__is_nullptr_t_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(414): error: not a class or struct name
: public integral_constant<bool, (__is_nullptr_t_helper<typename
^

/usr/local/include/c++/4.8.0/type_traits(459): error: integral_constant is not a template
: public integral_constant<bool, !is_fundamental<_Tp>::value> { };
^

/usr/local/include/c++/4.8.0/type_traits(459): error: not a class or struct name
: public integral_constant<bool, !is_fundamental<_Tp>::value> { };
^

/usr/local/include/c++/4.8.0/type_traits(463): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(467): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(472): error: integral_constant is not a template
: public integral_constant<bool, (__is_member_pointer_helper<
^

/usr/local/include/c++/4.8.0/type_traits(472): error: not a class or struct name
: public integral_constant<bool, (__is_member_pointer_helper<
^

/usr/local/include/c++/4.8.0/type_traits(481): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(485): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(490): error: not a class or struct name
: public false_type { };
^

/usr/local/include/c++/4.8.0/type_traits(494): error: not a class or struct name
: public true_type { };
^

/usr/local/include/c++/4.8.0/type_traits(499): error: integral_constant is not a template
: public integral_constant<bool, __is_trivial(_Tp)>
^

/usr/local/include/c++/4.8.0/type_traits(499): error: identifier "__is_trivial" is undefined
: public integral_constant<bool, __is_trivial(_Tp)>
^

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

found a similar post related to my issue here:

http://software.intel.com/en-us/forums/topic/392900

It seems that the way I use clang++ with -stdlib=libc++ -std=c++11 gives me all of the features i need.

it seems the inability to tell icpc that i want to use -stdlib=libc++ is the issue, as clang++ has compilation issues without the stdlib flag.

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

>>...how isn't the thread header in the appropriate /include directory?

It is a new addition in STL library. Let me give you some comparison on what is going on with different Visual Studios:

- VS 2005 - thread is Not supported
- VS 2008 - thread is Not supported
- VS 2010 - thread is Not supported
- VS 2012 - thread is supported

You need to download the most latest version of standalone STL library ( for Linux platforms ) in order to have that header and, of course, a C++ compiler should support latest C++ standard.

so just to be clear:

you're saying icpc is looking for the *LINUX* standard of libc++, which by default is not included with any OS X installation of gcc/g++ by either brew/macports/etc?

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

I did more digging.

I don't think a standalone version of the C++11 thread library is available yet, as there is a profiteer trying to sell a standalone version of this library: http://www.stdthread.co.uk/forum/index.php/topic,107.0.html

Even this developer says there is trouble with icpc. I am almost certain that the way you guys are asking the tbb_thread to wrap std:;thread is causing an issue, as it can correctly figure out the *type* of each parameter:

aProgram.c(736): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
argument types are: (void (double **&, typedefdStruct *&, double **&, double **&, double **&, double *&, int, int, int, int), <error-type>, <error-type>, <error-type>, <error-type>, <error-type>, <error-type>, int, int, int, int)
threads[j] = tbb::tbb_thread(calcWeights,std::ref(data),std::ref(nbhd),std::ref(W),std::ref(V),std::ref(local_eigs),std::ref(rho),K,d,start, end);

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

I did more digging.

I don't think a standalone version of the C++11 thread library is available yet, as there is a profiteer trying to sell a standalone version of this library: http://www.stdthread.co.uk/forum/index.php/topic,107.0.html

Even this developer says there is trouble with icpc. I am almost certain that the way you guys are asking the tbb_thread to wrap std:;thread is causing an issue, as it can correctly figure out the *type* of each parameter:

aProgram.c(736): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
argument types are: (void (double **&, typedefdStruct *&, double **&, double **&, double **&, double *&, int, int, int, int), <error-type>, <error-type>, <error-type>, <error-type>, <error-type>, <error-type>, int, int, int, int)
threads[j] = tbb::tbb_thread(aFunction,std::ref(data),std::ref(nbhd),std::ref(W),std::ref(V),std::ref(local_eigs),std::ref(rho),K,d,start, end);

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

note that what I just showed above is independent of whether the thread is declared as std::thread or tbb:thread:

aProgram.c(734): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
argument types are: (void (double **&, typedefdStruct *&, double **&, double **&, double **&, double *&, int, int, int, int), <error-type>, <error-type>, <error-type>, <error-type>, <error-type>, <error-type>, int, int, int, int)
threads[j] = std::thread(aFunction,std::ref(data),std::ref(nbhd),std::ref(W),std::ref(V),std::ref(local_eigs),std::ref(rho),K,d,start,end);

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

If you are using a version of gcc installed by port, keep in mind that the "g++" and "gcc" commands will still point to the Apple provided gcc 4.2.1 (on snow leopard at least).  I have gcc 4.8 installed on my mac (but no intel compilers), and to invoke that version of g++ i need to call it as "g++-mp-4.8".  Binaries produced by the port version of g++ are dynamically linked against an appropriate libstdc++, which in my case is /opt/local/lib/libstdc++.6.dylib.  

If you have gcc installed through ports, perhaps try adding -cxxlib=/opt/local/ (or whatever is appropriate for your machine and gcc version) to your icpc command line so that it uses the macports libstdc++ and not the system default libstdc++.

yeah I realized that, but those compilers aren't what I care about.

I understand what you're saying about calling the macports versions using the mp reference, however neither of these ports' libraries are being picked up by ICPC.

I tried your suggestion above, same error. It just seems like the intel compiler cannot use the C++11 threading library (and maybe other sophisticated features of this very young standard)  because of this libc++ issue.

Hopefully the pros will be able to consider this as a bug, since clang++ doesn't have these issues. I acknowledge that it could be a linking/include directory error, but so far it seems like it's related more to the absence of a downloadable complete C++11 STL (with threads). I could be totally wrong and overlooking something really simple, heh.

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

Can you provide a minimal test case that compiles for you in clang++ but bombs in icpc?

>>...note that what I just showed above is independent of whether the thread is declared as std::thread or tbb:thread:
>>
>>aProgram.c(734): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
>>argument...

Please provide a test case and I'm not surprized that TBB also fails.

attached.

compiles fine via clang++ (and replacing tbb/compat/thread with thread) using:

clang++ -g -std=c++11 -stdlib=libc++ -DDEBUG -O3 -o test testcase.c -liomp5 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lznz -lm -lz

and fails via icpc (using tbb/compat/thread) using:

icpc -g -std=c++11 -stdlib=libc++ -DDEBUG -O3 -o test testcase.c -I/opt/intel/tbb/include/ -liomp5 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lznz -lm -lz

note that I understand some of the flags are invalid, but those aren't the reasons why it's failing:

icpc: command line warning #10159: invalid argument for option '-std'
testcase.c(48): error: namespace "std" has no member "ref"
threads[j] = std::thread(threadFunc,std::ref(wutev),K,sectsize,sectsize);
^

testcase.c(48): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
argument types are: (void (whatever *, int, int, int), <error-type>, int, int, int)
threads[j] = std::thread(threadFunc,std::ref(wutev),K,sectsize,sectsize);
^

testcase.c(50): error: namespace "std" has no member "ref"
threads[j] = std::thread(threadFunc,std::ref(wutev),K,sectsize,sectsize);
^

testcase.c(50): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
argument types are: (void (whatever *, int, int, int), <error-type>, int, int, int)
threads[j] = std::thread(threadFunc,std::ref(wutev),K,sectsize,sectsize);
^

testcase.c(72): warning #592: variable "somedata" is used before its value is set
findNeighbours(somedata,w_e_struct,integer);
^

i'm hopeful this testcase successfully demonstrates that the error is independent of the calibre of skill heh.

Attachments: 

AttachmentSize
Downloadtext/x-csrc testcase.c1.37 KB
"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

Hi all,

libc++ support should be coming in the next major version of the compiler, which we've just wrapped up beta on not that long ago. You can sign up on the thread stickied at the top of this forum about the Composer XE 2013 SP1 beta, so you can try it out.

Brandon Hewitt
Technical Consulting Engineer

For 1:1 technical support: http://premier.intel.com

Software Product Support info: http://www.intel.com/software/support

Quote:

Brandon Hewitt (Intel) wrote:

Hi all,

libc++ support should be coming in the next major version of the compiler, which we've just wrapped up beta on not that long ago. You can sign up on the thread stickied at the top of this forum about the Composer XE 2013 SP1 beta, so you can try it out.

PHEW. I thought I was being a newb and missed something. #linkingishardbro :p

Thank you for this information Brandon. Much appreciated.

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

I've played around with the testcase a bit, and here is what I can say:

1) in your last quote I can see you are still using "-std=c++11" on an older icpc that does not know that name.  As mentioned before, use "-std=c++0x" if you are sticking with that version of icpc, or update to one that recognizes the c++11 standard as named.

2) I'm using intel compilers on linux, which while not quite the same as macos, is close enough that the info could be helpful.

3) I could not compile your code with the #include<tbb/compat/thread> but could compile it with #include <thread>

4) With gcc 4.6.3 I could not compile your code (w/ #include<thread>) with clang++ or gcc.  Icpc did compile, but did not work.

5) With gcc 4.7.3 all of icpc, g++ and clang++ compiled and ran your testcase.  Results are shown below.

I think your primary issue is that your gcc compat is at 4.2.x, as I could not get good results unless I was using gcc 4.7 compatibility.  You might also benefit from updating icpc, at least if you insist on using -std=c++11. All results shown are with #include<thread> instead of tbb.

icpc w/ gcc 4.6, compiles, does not work.

$ icpc -v
icpc version 13.1.3 (gcc version 4.6.3 compatibility)
$ icpc -std=c++11 -DDEBUG -O3 -o test testcase.cxx -lpthread
testcase.cxx(73): warning #592: variable "somedata" is used before its value is set
 findNeighbours(somedata,w_e_struct,integer);
 ^
$ ./test 
Number of threads:0

icpc w/ gcc 4.7, g++ and clang++, compiles and works.

$ g++ --version
g++ (Gentoo 4.7.3 p1.0, pie-0.5.5) 4.7.3
$ g++ -std=c++11 -DDEBUG -O3 -o test testcase.cxx -lpthread
$ ./test
Number of threads:6

$ icpc -v
icpc version 13.1.3 (gcc version 4.7.0 compatibility)
$ icpc -std=c++11 -DDEBUG -O3 -o test testcase.cxx -lpthread
testcase.cxx(73): warning #592: variable "somedata" is used before its value is set
 findNeighbours(somedata,w_e_struct,integer);
 ^
$ ./test
Number of threads:6

$ clang++ --version
clang version 3.3 (tags/RELEASE_33/final)
$ clang++ -std=c++11 -DDEBUG -o test testcase.cxx -lpthread
$ ./test 
Number of threads:6

It also works if I tell icpc to use clang headers/libraries

$ icpc -std=c++11 -DDEBUG -use-clang-env -O3 -o test testcase.cxx -lpthread
testcase.cxx(73): warning #592: variable "somedata" is used before its value is set
 findNeighbours(somedata,w_e_struct,integer);
 ^
$ ./test
Number of threads:6

yeah it should work on a linux distribution.

The way osx implements the C++11 standard is a little weird, i think. 

nonetheless, i'll just wait for the sp1 to come out and see if it goes away.

fwiw: the c++11 and c++0x flags both chuck the same sort of error on my end. i am pretty sure intel just needs to make some subtle adjustments for osx. 

i appreciate your exhaustive evaluation of the testcase to shed more insight on what the issue is. it definitely seems like a niche problem for OSX users, which seems to have been fixed in SP1 (or they say, let's hope).

thanks again casey.

"Natural knowledge has not forgone emotion. It has simply taken for itself new ground of emotion, under impulsion from and in sacrifice to that one of its 'values', Truth." - Sir Charles Sherrington

[ Gagan wrote ]

>>...i'm hopeful this testcase successfully demonstrates that the error...

This is to let you know that I've reproduced the problem ( on a Windows platform as well ) and I'll look at it next week.

[ Compilation Output ]

...
Test037.cpp(43): error: namespace "std" has no member "ref"
threads[j] = std::thread(threadFunc,std::ref(wutev),K,sectsize,sectsize);
^
Test037.cpp(43): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
argument types are: (void (whatever *, int, int, int), , int, int, int)
threads[j] = std::thread(threadFunc,std::ref(wutev),K,sectsize,sectsize);
...

>>It is a new addition in STL library. Let me give you some comparison on what is going on with different Visual Studios:
>>
>>- VS 2005 - thread is Not supported
>>- VS 2008 - thread is Not supported
>>- VS 2010 - thread is Not supported
>>- VS 2012 - thread is supported

I confirm this and with STL headers released in 2012 compilation error
...
Test037.cpp(43): error: namespace "std" has no member "ref"
...
is not displayed ( everything is good because thread header is present ) but the second error still displayed and it means that there is some issue with TBB. Updated test-case attached.

Attachments: 

AttachmentSize
Downloadtext/x-c++src test037.cpp2.5 KB

>>...but the second error still displayed and it means that there is some issue with TBB...

I mean this one:

...
Test037.cpp(43): error: no instance of constructor "tbb::internal::tbb_thread_v3::tbb_thread_v3" matches the argument list
argument types are: (void (whatever *, int, int, int), , int, int, int)
threads[j] = std::thread(threadFunc,std::ref(wutev),K,sectsize,sectsize);
...

Leave a Comment

Please sign in to add a comment. Not a member? Join today