Intel® Moderncode for Parallel Architectures
Support for developing parallel programming applications on Intel® Architecture.

Intel Thread Checker 3.0 Beta on Linux


We are having a problem using Intel Thread Checker 3.0 Beta for Linux.

We have got the tool running on a Fedora Core 4 PC. The command-line tool is able to check PThreads and OpenMP programs and produces reports in several available formats including HTML, formatted ASCII text, CSV, XML-based TXF and THR formats.

The problem is that the tool does not resolve relative addresses into line numbers in the reports, so that we get the line

Thread termination at [heat2, 0x9ff] - includes stack
allocation of 2101248 and use of 4088 bytes

instead of

Thread termination at line 38 of "heat1.c" - includes stack
allocation of 2101248 and use of 4088 bytes

This is a significant problem since we intend to use the threadchecker in our parallel programming course for beginners.

I would appreciate any advice on this problem. Also I wonder if the descriptions of the XML based formats such as TXF or THR are available for the users.

Here are some details of the system and usage:

System: Fedora Core 4 based Linux distribution, linux 2.6.16 up,
gcc 4.0.2, intel compilers 9.0, Genuine Intel Pentium 4 CPU

(bash) export OMP_NUM_THREADS=8
(bash) icc -openmp -g -o heat2 heat1.c
(bash) tcheck_cl -html ./heat2
0 Kudos
2 Replies

this is just a reminder for myself and for these concerned with the issue.

To check OpenMP parallelized programs one has to run the compiler with
(bash) icc -tcheck -openmp -g
this produces an executable which runs with the special threadchecker openMP libraries instead of the normal ones. In particular, the value of OMP_NUM_THREADS is not respected. The report produced by the tcheck_cl program contains resolved line numbers and variable names.

Here is a question though: is it possible to run a tcheck instrumented OpenMP program with a number of threads different from two?

Black Belt
Dmitri is correct about the compile/link/run options required for use of tcheck_cl. In addition, it appears that the 64-bit tcheck_cl was not built correctly until this week. I suppose we are to assume that someone is running the 32-bit OS, when they don't specify.