Community
cancel
Showing results for 
Search instead for 
Did you mean: 
YannGolanski
Beginner
39 Views

symbolic information may not be available due to inline assembly

I was wondering what this error message means. My code does link to a few home grown libraries but none of them contain any threaded code. The only thing that does contain threaded code is a call in remeasure.cc which uses parallel_for. Sadly, when I compile the code to see f thread checker can tell me why it is slower than un-threaded code I get this error. I am not sure what to do next. Any help would be appreciated.

$ gmake clean all
Building dependencies ...
Cleaning all junk ...
Compiling remeasure.cc ...
icpc -g -O0 -tcheck -I/usr/local/climetpackages/include -I/usr/local/include/boost-1_37 -I../../../../common/src/clib/ -I../ -I/opt/intel/Compiler/11.0/069/tbb/include -DPIXEL_DEPTH_U8 -c remeasure.cc -o remeasure.o
remeasure.cc: remark: symbolic information may not be available due to inline assembly; results may not be usable by Intel Thread Checker.
Compiling singleton_log4cxx.cc ...
icpc -g -O0 -tcheck -I/usr/local/climetpackages/include -I/usr/local/include/boost-1_37 -I../../../../common/src/clib/ -I../ -I/opt/intel/Compiler/11.0/069/tbb/include -DPIXEL_DEPTH_U8 -c singleton_log4cxx.cc -o singleton_log4cxx.o
Linking object files ...
icpc -o remeasure -I/usr/local/climetpackages/include -I/usr/local/include/boost-1_37 -I../../../../common/src/clib/ -I../ -I/opt/intel/Compiler/11.0/069/tbb/include -L/usr/local/climetpackages/lib -L/usr/local/lib -L../ -lboost_program_options-il-mt -lboost_filesystem-il-mt -lboost_system-il-mt -lboost_regex-il-mt -lpthread -loverlayMeasurement -g -tcheck -L/opt/intel/itt/tcheck/bin/32 -L../../../../common/src/clib/ -lclib -lm -llog4cxx -lstdc++ -ltbb ./remeasure.o ./singleton_log4cxx.o
icpc: warning #10164: thread checking compilation disables optimization

0 Kudos
3 Replies
Alexey_K_Intel3
Employee
39 Views

Quoting - nanometrics

I was wondering what this error message means. My code does link to a few home grown libraries but none of them contain any threaded code. The only thing that does contain threaded code is a call in remeasure.cc which uses parallel_for. Sadly, when I compile the code to see f thread checker can tell me why it is slower than un-threaded code I get this error. I am not sure what to do next. Any help would be appreciated.


I do not see any error in the output you provided. There is one compilation remark and one link warning, and both seem benign to me.

Indeed, TBB uses inline assembly code; on Linux, atomic operations used everywhere in TBB are implemented as inline assembly. I'd guess however thatthe remark only applies to the inline assembly part and not to the whole object file, but I am not sure.

As for the warning about disabling optimization, it's benign since you compiled the code with -O0 anyway. Since you use the compiler driver to link, may be adding -O0 to the link command will shut up this warning. And if it bothers you, go to Premier Support and submit a bug. Or just ignore it.

What bothers me however is that you said "to see if thread checker can tell me why it is slower than un-threaded code". If you want performance analysis (as implied by "why it is slower"), you should use either VTune or Thread Profiler; Thread Checker will tell you where correctness issues in your code are (if any), such as data races & deadlocks.

YannGolanski
Beginner
39 Views


I do not see any error in the output you provided. There is one compilation remark and one link warning, and both seem benign to me.

Indeed, TBB uses inline assembly code; on Linux, atomic operations used everywhere in TBB are implemented as inline assembly. I'd guess however thatthe remark only applies to the inline assembly part and not to the whole object file, but I am not sure.

As for the warning about disabling optimization, it's benign since you compiled the code with -O0 anyway. Since you use the compiler driver to link, may be adding -O0 to the link command will shut up this warning. And if it bothers you, go to Premier Support and submit a bug. Or just ignore it.

What bothers me however is that you said "to see if thread checker can tell me why it is slower than un-threaded code". If you want performance analysis (as implied by "why it is slower"), you should use either VTune or Thread Profiler; Thread Checker will tell you where correctness issues in your code are (if any), such as data races & deadlocks.

Indeed, there are no errors, just the remark that worries me. I don't like things not running smoothly.

Sadly, there is a deeper problem. I added a "foo++;" instruction within the parallel loop where "static int foo". Yet, the report from tchecker gives me no warning/error for this. Thus, I assumed that the remark caused this error not to appear. I could be wrong.

I am currently doing lots of optimisation and checking my code. Mostly it is learning about Vtune and thread checker. Hence the array of questions.

Thanks.

39 Views

Quoting - nanometrics

Sadly, there is a deeper problem. I added a "foo++;" instruction within the parallel loop where "static int foo". Yet, the report from tchecker gives me no warning/error for this. Thus, I assumed that the remark caused this error not to appear. I could be wrong.

Thank you for the report, it definitely seems a shortcoming in TBB's support by tools. While we are investigating it, could you please try binary instrumentation as workaround? I.e., drop -tcheck from compiler's command lines, and run resulted binary in form

tcheck_cl ./remeasure ...