ThreadChecker message "undefined in the serial code", but the code is in an non OpenMP code part

[FDSUser]

All,

from Intel Thread Checker 3.1 (newest version) I got the follwing message:

[plain]OpenMP* -- undefined in the serial code (original program) at "isob.c":2132 with "dump.f90":748 [/plain]

I do not understand the message, because this lines are not in an OpenMP part of the code. The code, on which this message is based on is as following:
The main.f90 file (a serial file with no OpenMP-Code) calls a subroutine at the dump.f90-file. In this subroutine (after a part of OpenMP-Code) line 748 (in the serial part of the code) calls a C-Subroutine (no OpenMP-Code) by using a Fortran Interface(no OpenMP-Code). So, I do not understand this message, because I'm in the serial part of my program. Have a look at the code
This is the Code in dump.f90 (line 748), which calls the C-Routine

[cpp]CALL SMOKE3DHEADER(TRIM(FN_SMOKE3D(1,NM))//CHAR(0),0,M%IBAR,0,M%JBAR,0,M%KBAR)[/cpp]

The C-Routine is called via an Fortran Interface, which is:

[cpp]interface

subroutine smoke3dheader(file,is1,is2,js1,js2,ks1,ks2)

!DEC$ ATTRIBUTES C :: SMOKE3DHEADER
!DEC$ ATTRIBUTES REFERENCE :: FILE,IS1,IS2,JS1,JS2,KS1,KS2
character(len=*), intent(in) :: file
integer, intent(in) ::is1,is2,js1,js2,ks1,ks2

end subroutine smoke3dheader[/cpp]

The C-Routine itself is

[cpp]#include 
#include 
#include 
#include 

#ifndef pp_noappend
#define CCsmoke3dheader smoke3dheader_
#define CCsmoke3dtofile smoke3dtofile_
#else
#define CCsmoke3dheader smoke3dheader
#define CCsmoke3dtofile smoke3dtofile
#endif

unsigned int rle(unsigned char *buffer_in, int nchars_in, unsigned char *buffer_out);

void CCsmoke3dheader(char *file,int *is1, int *is2, int *js1, int *js2, int *ks1, int *ks2){
  FILE *binfile,*textfile;
  int nxyz[8], VERSION=0;
  char textfilename[1024];

  nxyz[0]=1;
  nxyz[1]=VERSION;
  nxyz[2]=*is1;
  nxyz[3]=*is2;
  nxyz[4]=*js1;
  nxyz[5]=*js2;
  nxyz[6]=*ks1;
  nxyz[7]=*ks2;



  binfile=fopen(file,"wb");
  if(binfile==NULL)return;
  fwrite(nxyz,  4,1,binfile);
  fwrite(nxyz+1,4,7,binfile);
  fclose(binfile);

  strcpy(textfilename,file);
  strcat(textfilename,".sz");
  textfile=fopen(textfilename,"w");
  fprintf(textfile,"%in",VERSION);
  fclose(textfile);
}[/cpp]

The line

[cpp]strcpy(textfilename,file);
[/cpp]

is line 2132 in the file isob.c, which is shown in the message.

It would be great if anybody could help me with this problem.
Thanks for your help
Christian

[jimdempseyatthecove]

Christian,

When writing for OpenMP you are writing for multi-threaded programming and will (should) be linking the the multi-threaded libraries. When compiling with OpenMP the multi-threaded libraries may have hooks in it for use with OpenMP.

In particular the fortran WRITE and C runtime system counterpart (Fortran uses C runtime system routines in the lower levels), these writestatements must serialize itself with OpenMP threads. WRITE is not compiled differently when called within a parallel region (as the write might beissued within a subroutine compiled without a parallel region, however being call from within a parallel region from the calling subroutine (or within a higher layer).

As such, WRITE must make a determination as to if it is in an OpenMP parallel region or not. To do this it calls an OpenMP subroutine (function).

My guess is the C++ function/subroutine is compiled without OpenMP enabled (and without the debug symbols for OpenMP) and when it calls fprintf or fwrite and enters into the OpenMP aware code, that it has no symbols for thread checker to use in report generation.

Jim Dempsey

[FDSUser]

Quoting - jimdempseyatthecove

Christian,

When writing for OpenMP you are writing for multi-threaded programming and will (should) be linking the the multi-threaded libraries. When compiling with OpenMP the multi-threaded libraries may have hooks in it for use with OpenMP.

In particular the fortran WRITE and C runtime system counterpart (Fortran uses C runtime system routines in the lower levels), these writestatements must serialize itself with OpenMP threads. WRITE is not compiled differently when called within a parallel region (as the write might beissued within a subroutine compiled without a parallel region, however being call from within a parallel region from the calling subroutine (or within a higher layer).

As such, WRITE must make a determination as to if it is in an OpenMP parallel region or not. To do this it calls an OpenMP subroutine (function).

My guess is the C++ function/subroutine is compiled without OpenMP enabled (and without the debug symbols for OpenMP) and when it calls fprintf or fwrite and enters into the OpenMP aware code, that it has no symbols for thread checker to use in report generation.

Jim Dempsey

Jim,

thanks for your reply. But I compile the code (Fortran and C) with the openmp flag. I comile using

[plain]icc -c -O0 -g -Dpp_noappend -no-multibyte-chars -tcheck -openmp -ltcdata -traceback isob.c
ifort -c -O0 -g -vec_report0 -tcheck -openmp -ltcdata -FR -auto -WB -traceback -fpe0 -fltconsistency  [/plain]

so, the -g, -tcheck and -traceback flags are used for compilation of Fortran and C. I tried different compilation flags, but the ThreadChecker warning is still the same.
Maybe this helps...

Regards,
Christian

[TimP]

Quoting - FDSUser

[plain]icc -c -O0 -g -Dpp_noappend -no-multibyte-chars -tcheck -openmp -ltcdata -traceback isob.c
ifort -c -O0 -g -vec_report0 -tcheck -openmp -ltcdata -FR -auto -WB -traceback -fpe0 -fltconsistency  [/plain]

so, the -g, -tcheck and -traceback flags are used for compilation of Fortran and C. I tried different compilation flags, but the ThreadChecker warning is still the same.

-tcheck over-rides many of those flags, so they shouldn't have any effect until you remove -tcheck.
-tcheck set -O0 -g, removing the effect of -vec-report -fltconsistency
-openmp sets -auto
So, you can't expect the options to be implicated in any warnings given by -tcheck.
-fltconsistency is deprecated for those compiler versions which offer -fp-model (all currently supported versions).