Bug report with -tcheck

[Tim]

Hallo,

I try to compile a bigger code with binary instrumentation for the Intel Thread Checker with "-tcheck":

icpc -DiMOOSE_EXPORTS -DUSE_OPENMP -DMAX_NUM_THREADS=100 -DUSE_LIS -DOORELEASESTR=\\"head\\" -DOOVERSSTR=\\"0.99\\" -openmp -g -O0 -tcheck -fPIC -I/home/tc530841/iMOOSE/head/oovr/source -o CMakeFiles/iMOOSE.dir/vecmat/vect.o -c /home/tc530841/iMOOSE/head/oovr/source/kernel/vecmat/vect.cc

Unfortunately, I get a internal compiler error:

ngmatrixinterface.cc(184) (col. 2): internal error: 0_1871

Code snippet:

[cpp]Connection*
IntConnectionFactory::build(FemMesh::ConstSmPtr mesh,
            vector >& dofKomp2Row,
            const map& numDofs) const
{

// do preparations

  #pragma omp parallel for //LINE 184
for(int m=0; m 
The error is reported in the line containing the openmp pragma. After uncomment this line I get the same error for another pragma, which is also in templete method. I know it might be hard to reproduce this issue, but I dont know how to write a small test case for this issue. What does errror 0_1871 mean? Is there a solution / workaround? 

When building without "-tcheck" everthing works just fine. Any ideas?

Cheers,
Tim

[Milind_Kulkarni__Int]

Can you let me know the compiler version, and tcheck version, also the OS you are using like RHEL etc. also, try using the later compilers.

I think this is a bug, and wehave the same bug (0_1871) with -tcheck -openmp in our bug record database, but its still not fixed yet. Also for your case, does this bug occur when -openmp option is not used??

As a workaround for now, you can try not building with -tcheck, and try out whether ThreadChecker still works for you,i.e, if you use -g (for debugging symbols), though this looks somewhat against whats mentioned in the doc.

Also, just to confirm whether thats the same bug, can youattach here (or through Private Post as a reply to this thread), your project, or produce compilable Preprocessed .i file (by using -E or -EP option), so that we can reproduce and analyze.

As for your question, 0_1871 is an internal error, and they are errors in compiler code itself as I think so, and that is the reason, why this error cannot be mapped to the error in your source code, as the line it comes in is often also not the actual line the error IS, due to this same reason.
So you can never know why come in your code.

[Tim]

Hi Milind,

thanks for your support and detailed answer.

Quoting Milind Kulkarni (Intel)

Can you let me know the compiler version, and tcheck version, also the OS you are using like RHEL etc. also, try using the later compilers.

Sorry forgot to mention my environment:

$ cat /proc/version
Linux version 2.6.18-128.7.1.el5_sunhpc1 (giraffe-bot@giraffe-stack-centos53.co.cfs) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Mon Jan 4 16:16:30 MST 2010

$ tcheck_cl --version
Intel Thread Checker 3.1 command line instrumentation driver (26185)
Copyright (c) 2007 Intel Corporation. All rights reserved.

$ icpc --version
icpc (ICC) 11.1 20100414
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

For the compiler i also tried version: "icc (ICC) 11.1 20100203" and "icc (ICC) 12.0.1 20100706" (Beta) with the same result.

Quoting Milind Kulkarni (Intel)

I think this is a bug, and we have the same bug (0_1871) with -tcheck -openmp in our bug record database, but its still not fixed yet. Also for your case, does this bug occur when -openmp option is not used??

No, if I dont use -openmp this is not an issue. But linking fails, because of some "undefined reference to `__kmpc_ok_to_fork'" issues, which is clear, because I link against a lib which uses openmp. Anyway, finding race conditions in non parallel Code is not that difficult. ;-)


Quoting Milind Kulkarni (Intel)

As a workaround for now, you can try not building with -tcheck, and try out whether ThreadChecker still works for you, i.e, if you use -g (for debugging symbols), though this looks somewhat against whats mentioned in the doc.

You are talking about source instrumentation instead of binary instrumentation? This works, but it reports a
lot of false positives which makes it really difficult to identify the relevant issues. Our code uses a lot of C++ template techniques and object-oriented stuff, so its quite hard to analyse each reported issue.


Quoting Milind Kulkarni (Intel)

Also, just to confirm whether thats the same bug, can you attach here (or through Private Post as a reply to this thread), your project, or produce compilable Preprocessed .i file (by using -E or -EP option), so that we can reproduce and analyze.

The point is: I am not sure if i am allowed, cause it is not full open source. Another problem is that there a several dependencies, so it is quite hard to build anyway. I will check for a possibilty....


Quoting Milind Kulkarni (Intel)

As for your question, 0_1871 is an internal error, and they are errors in compiler code itself as I think so, and that is the reason, why this error cannot be mapped to the error in your source code, as the line it comes in is often also not the actual line the error IS, due to this same reason.
So you can never know why come in your code.

Ok, thank for that explanation.

Is it possible to sign in to a notification list or something like that for this bug, so that I know when it will be fixed?

Kind Regards,
Tim

[Milind_Kulkarni__Int]

thanks for the detail clarification..

Yes, you can check possibilty of sending it, or also see whether you can narrow it down ..
The bug for our case also comes with tcheck 3.1 only..

The point to omit -openmp was just to check whether anything else is the cause of Internal Error..

There is no need to sign in. I will escalate this thread, and point it to the appropriate bug record in database upon checking with team whether that is same bug 0_1871, and when itwill beimplemented, I will Notify you in this thread, or via email.

In case you want the bug-id # for reference, I will let you know after checking.

[Tim]

Thanks again. I would like to receive a mail after this is fixed. At the moment i dont have any idea how to narrow it down. That was the reason why I asked for the error number, to get a hint what the problem could be. I will see what I can do... If you have any furhter questions that could help you to fix the bug please feel free to contact me via mail.

Cheers,
Tim

[Milind_Kulkarni__Int]

As I heard latest, 0_1871 bug is not seen in latest version of 11.1.
And the bug owner closed the issue saying it does not appear anymore..
Can you try with l_cproc_p_11.1.073 , or even 072, both have it fixed.

After you check the result & the geographical restrictions of your code, you may post code privately in this thread, so its not readable by public.

Though for your reference, the bug# was DPD200142450..

[Tim]

We dont have 11.1.073 installed, but i tested with 072 and 12.0.048 (beta!). In all cases I get the same 0_1871 error. I cannot test another threadchecker version, cause we only have 3.1.009 installed.

It would be for you enough for you to get the *.i file produces by the preprocessor to reproduce this bug, isnt it?

[Milind_Kulkarni__Int]

It was lots of code, really. After much struggle narrowing down, I finally developed very simple test-case..

[bash]#include 
#include 
int build()
{
std::valarray items(100);

        #pragma omp parallel for
        for(int m=0; m
It seems -tcheck whines with valarrays + openmp combined togetherfor a simple case too, and seems a defect.

Please also let me know whether you get that  with this simple code ..

[Milind_Kulkarni__Int]

Andthe tcheck errormay not be for all openmp pragmas, or may be for more..

For eg.

changing :--

[bash]#pragma omp parallel for   [/bash]

to

[bash]#pragma omp parallel
[/bash]

For The above, simply goes away..

Another interesting case, openmp + all give this error with -tcheck..

It does not need to be valarray..

Since this is a very simple case, we need to check with the latest version of tcheck, which could have its fix ..

But more than -tcheck, I think it has to do with compiler, as -openmp is also required to reproduce bug.

Its a defect as the latest compilers also do not have this fix.. I will escalate it.

Thanks for bringing this issue..

[Tim]

Hi Milind,

wow. Narrow down 100000 lines of code to 11 is really good work :-P. The error also occurs for this simple test case and all three compiler versions (even the 12beta). Please let me know if there is a version of the Thread Checker / Compiler which fix this issue.

So for, thank you very much for your quick and excellent help. Looking forward to the fix.

Cheers,
Tim

[Milind_Kulkarni__Int]

yes, it comes with latest compilers too..

The simple case does not show problem in Windows compilers, though .
The driver number (version) is different in Windows & Linux, but I tested with slightly older version in Windows.

Anyways, I have escalated the issue for Linux.
And, if I get any headway in Linux against that error, I will inform you..

The tcheck I checked in Linux is the newest version, see if the version you used was :-- 27583..

thanks

[wcharlot]

yes, that's right. it would be better if you consult on Linux first because they probably know how to work on that issue.

[Milind_Kulkarni__Int]

We are not supporting -tcheck any more . So, this issue will not be fixed