Compiler catastrophic error with OpenMP

Compiler catastrophic error with OpenMP

I used 11.0.083 to compile my program and following happened:

bi_cgstab.for(491): (col. 7) remark: OpenMP DEFINED LOOP WAS PARALLELIZED.
bi_cgstab.for(487): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
bi_cgstab.for(43): (col. 7) remark: OpenMP DEFINED LOOP WAS PARALLELIZED.
bi_cgstab.for(40): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
bi_cgstab.for(87): (col. 7) remark: OpenMP DEFINED LOOP WAS PARALLELIZED.
0_11442

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

compilation aborted for bi_cgstab.for (code 3)

I decided to try finding the cause of this error before reporting it to Intel. I realized that it helped to remove the line with FIRSTPRIVATE from the following code:

!dec$ if defined (_PARALLELIZATION_)  
!$omp parallel if ( enableOpenMP .AND. omp_solvers ) num_threads ( threads ) default ( shared )  
!$omp&  private ( i, j, k, l, P1, P2, P3 )  
!$omp&  firstprivate ( alpha_SIP )  
           
!$omp do schedule(dynamic,3)  
!dec$ end if
          do i=2,nx-1
          ...

I have already had problem with FIRSTPRIVATE used for variables whose values are just used and not changed within the parallel region, see e.g. here (this was in Windows). alpha_SIP is real*8, initialized before the parallel region (which is not nested - it is called by the main level thread), and it is not changed inside the region.

Should there be anything wrong about using FIRSTPRIVATE for variables which in fact do not need it, because DEFAULT(SHARED) is used?

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Regardless of any deficiencies of your source code, if it provokes internal compiler error, the invitation to submit a reproducer problem report is sincere. firstprivate implies that a copy is made for each thread. If the compiler recognizes that the copy is unnecessary, but blows up in an attempt to take advantage of that observation, it appears to be a reportable bug.

I understand how FIRSTPRIVATE should work; I am having a discussion on FIRSTPRIVATE with Jim Dempsey in the Windows forum.
I tried creating a reproducer problem, but everything worked well in it. This means that I would have to submit the original file which I am not allowed to. How does it work with confidentiality when I submit some source code files which I don't want to disclose to anybody but Intel developers who would be dealing with the issue?

For confidential submission of source code, your support account on premier.intel.com is preferable. There are provisions on this forum for private attachments, but that would not be the preferred method.

I have just submitted this issue on premier.intel.com. I will present their response here when I know for sure what was causing the problem.

Update: I have been told by Intel Developer Support that "This has already been fixed in our 11.1 compiler which is scheduled for release at the end June. The 11.1 beta program is coming to a close."

Leave a Comment

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