11.0 083 catastrophic error with openmp

[riverseow]

I am new here. However, I have been using Intel compiler for 4 years. Today, I got into a problem that I could not solve. I googled it but did not get any good information.

I have a program that works under intel compiler for many years. I did not change the code. I just upgrade the intel compiler from 11.0 074 to 11.0 083. Using the same compilation setting, I got the following errors:

": catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error."

Using 11.0.074, my compilation is sucessful. But using 083 I will get the error above. I only using the following flags for compilation:

-O2 -openmp -132 -warn all

I removed the flag "-openmp" and the compilation succeeds. I read some related thread about "FIRSTPRIVATE" in opemp might cause this. However, I do not use any FIRSTPRIVATE. I could not figure out which line cause this problem because the line report by the compiler does not corespond to the original source code. Any help would be appreciated.

River

[Ron_Green]

It looks like a compiler bug in 083. Can you post the source file to this forum thread (see my signature below for the URL that describes uploading files)

ron

[riverseow]

Quoting - Ronald Green (Intel)

It looks like a compiler bug in 083. Can you post the source file to this forum thread (see my signature below for the URL that describes uploading files)

ron

My main source code is 9000 lines and with different dereviative controled compilation (-Dxxxx), some with openmp, some with mpi, some use fftw, some do not use fftw. How can I generated the code that corespondent to the problem? I could not narrow down where the problem is because the line number showed by the compiler do not match the original code. I tried to use -E or -EP to dump the pre-processed code but still the line does not match what shows by the compiler. Do you have any suggestions for me to first narrow down the problem or generate a much shorter version of the code that can show the problem?

[Ron_Green]

Quoting - riverseow

My main source code is 9000 lines and with different dereviative controled compilation (-Dxxxx), some with openmp, some with mpi, some use fftw, some do not use fftw. How can I generated the code that corespondent to the problem? I could not narrow down where the problem is because the line number showed by the compiler do not match the original code. I tried to use -E or -EP to dump the pre-processed code but still the line does not match what shows by the compiler. Do you have any suggestions for me to first narrow down the problem or generate a much shorter version of the code that can show the problem?

The line number given is inside the compiler source, not your source files. It will not map to your source line.

I would not worry about narrowing it down, that's what they pay me for :)

If you have a makefile, just tar it all up and attach it. OR attach the source(s) and give instructions for building. Keep in mind, everyone on the Internet will see this - is that OK? If you want to keep it private you can send it to me via email directly.

ron

[riverseow]

Quoting - Ronald Green (Intel)

The line number given is inside the compiler source, not your source files. It will not map to your source line.

I would not worry about narrowing it down, that's what they pay me for :)

If you have a makefile, just tar it all up and attach it. OR attach the source(s) and give instructions for building. Keep in mind, everyone on the Internet will see this - is that OK? If you want to keep it private you can send it to me via email directly.

ron

I would rather just send to you by email in a tar.gz file. Can I just send you the main source. So long you get to the object file (.o) successfully, I can link it to those libaries. However, I might need to give you all the header files. How to send to your email. Is there any private message that you can let me know your email address?

[rreis]

are you using also the -traceback flag? just to make sure...

[Ron_Green]

Quoting - rreis

are you using also the -traceback flag? just to make sure...

Ricardo, -traceback only works at runtime on executables created by the compiler. In this case, the compiler itself is aborting, so traceback does not apply. Internally, we have debug builds of the compiler. So we simply load the debug compiler into idb or gdb and run it with the arguments used on the compile line and see where it crashes. Then we open a bug report with the source and the stack trace. Often we'll cut the testcase down to as few lines as possible by systematically removing source until the minimum syntax is present to cause the crash.

Just like application debugging. :)

ron

[riverseow]

Quoting - rreis

are you using also the -traceback flag? just to make sure...

No. I am not using the "-traceback" flag.

[rreis]

Quoting - Ronald Green (Intel)

Ricardo, -traceback only works at runtime on executables created by the compiler. In this case, the compiler itself is aborting, so traceback does not apply. Internally, we have debug builds of the compiler. So we simply load the debug compiler into idb or gdb and run it with the arguments used on the compile line and see where it crashes. Then we open a bug report with the source and the stack trace. Often we'll cut the testcase down to as few lines as possible by systematically removing source until the minimum syntax is present to cause the crash.

Just like application debugging. :)

ron

thanks for the explanation. I hadn't noticed it was the compiler that needed debugging :)