Re: Compile error with 11.1.035

DavidWhite · ‎06-23-2009

My project builds OK under 11.0, but not under 11.1

[cpp]    REAL(KIND=8) CLASS(CUTS)

    CLASS = 1D0 

ymd_calculate.f90(563): error #5143: Missing mandatory separating blank
ymd_calculate.f90(563): error #5082: Syntax error, found IDENTIFIER 'D0' when expecting one of: * ) :: ,  ; + . - (/ [ : ] /) ' ** / // > .LT. ...
ymd_calculate.f90(563): error #6404: This name does not have a type, and must have an explicit type.   [D0][/cpp]

What is wrong with the array assignment CLASS = 1D0? Appears that the compiler is not distinguishing between CLASS as a key word and as a variable??

Andrew_Smith · ‎06-24-2009

Quoting - David White

My project builds OK under 11.0, but not under 11.1

[cpp]    REAL(KIND=8) CLASS(CUTS)

    CLASS = 1D0 

ymd_calculate.f90(563): error #5143: Missing mandatory separating blank
ymd_calculate.f90(563): error #5082: Syntax error, found IDENTIFIER 'D0' when expecting one of: * ) :: ,  ; + . - (/ [ : ] /) ' ** / // > .LT. ...
ymd_calculate.f90(563): error #6404: This name does not have a type, and must have an explicit type.   [D0][/cpp]

What is wrong with the array assignment CLASS = 1D0? Appears that the compiler is not distinguishing between CLASS as a key word and as a variable??

What happens with:

CLASS = 1.0D0

Steven_L_Intel1 · ‎06-24-2009

I can reproduce the problem, and I agree with the theory that the compiler is confusing the keyword CLASS. I'll report this to the developers. Issue ID DPD200137215.

drbath · ‎07-09-2009

Quoting - Steve Lionel (Intel)

I can reproduce the problem, and I agree with the theory that the compiler is confusing the keyword CLASS. I'll report this to the developers. Issue ID DPD200137215.

Has this issue been fixed? I'm having a similar issue with the COMPLEX key word. I'm using version 11.0.074

Steven_L_Intel1 · ‎07-09-2009

The CLASS keyword issue is being fixed, but the fix won't be available for a month or so. Do you have an example showing a problem with COMPLEX?

drbath · ‎07-09-2009

Quoting - Steve Lionel (Intel)

The CLASS keyword issue is being fixed, but the fix won't be available for a month or so. Do you have an example showing a problem with COMPLEX?

V1CO = VTEMP*GXMIT1*SQRT(SGMACO1/2.)
& *COMPLEX(NOISE(ZERO,ONE),NOISE(ZERO,ONE))

Getting error #6404: This name does not have a type, and must have an explicit type. (COMPLEX).

Not sure what else you need for COMPLEX example, without pasting the whole file (let me know if you need anything else).

drbath · ‎07-09-2009

Quoting - drbath

V1CO = VTEMP*GXMIT1*SQRT(SGMACO1/2.)
& *COMPLEX(NOISE(ZERO,ONE),NOISE(ZERO,ONE))

Getting error #6404: This name does not have a type, and must have an explicit type. (COMPLEX).

Not sure what else you need for COMPLEX example, without pasting the whole file (let me know if you need anything else).

Forgot to mention, it complies under gfortran.

Steven_L_Intel1 · ‎07-09-2009

Quoting - drbath

Forgot to mention, it complies under gfortran.

Well, that's nice, but there's no such feature in Fortran 2003. Maybe you meant CMPLX? There was a proposal to add a COMPLEX "type constructor" to Fortran 2008, but it was rejected. It would not surprise me if gfortran went ahead and implemented it.

drbath · ‎07-10-2009

Quoting - Steve Lionel (Intel)

Well, that's nice, but there's no such feature in Fortran 2003. Maybe you meant CMPLX? There was a proposal to add a COMPLEX "type constructor" to Fortran 2008, but it was rejected. It would not surprise me if gfortran went ahead and implemented it.

CMPLX seems to work. Thanks for the help.

DavidWhite · ‎07-24-2009

Quoting - Steve Lionel (Intel)

The CLASS keyword issue is being fixed, but the fix won't be available for a month or so. Do you have an example showing a problem with COMPLEX?

This error (CLASS) is still in 11.1.038.

Steven_L_Intel1 · ‎07-24-2009

Quoting - David White

This error (CLASS) is still in 11.1.038.

Yes, it would be. The August update would be the first where it might be fixed.

Steven_L_Intel1 · ‎08-13-2009

I expect the fix for this bug to be included in the next update, sometime within the next month.

admin2 · ‎09-10-2009

Quoting - Steve Lionel (Intel)

I expect the fix for this bug to be included in the next update, sometime within the next month.

Does anyone know if this has been fixed in 11.1.046? I've got the same problem but with a different application DL_POLY v3.10 :

http://www.cse.scitech.ac.uk/ccg/software/DL_POLY/

mpif90 -c -ip -O3 comms_module.f90
comms_module.f90(638): error #6404: This name does not have a type, and must have an explicit type. [MPI_WTIME]
tzero = MPI_WTIME()

"mpif90 -echo" returns (i.e. what is mpif90 really running):

+ '[' no = no ']'
+ unset 'allargs[0]'
++ expr 0 + 1
+ argno=1
+ '[' 1 -eq 0 ']'
+ '[' no = yes ']'
+ mpilibs='-lmpichf90 -lmpich'
+ F90FLAGS=
+ LDFLAGS=' '
+ '[' -n '' ']'
+ '[' -z -I ']'
+ F90INCDIRS=-I/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/include
+ moduledir=/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/include
+ modulelib=mpichf90
+ '[' -n '' ']'
+ '[' -n -I ']'
+ F90MODDIRS=-I/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/include
+ F90MODLIBS=-lmpichf90
+ '[' yes = yes ']'
+ '[' -n '' ']'
+ ifort -I/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/include -I/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/include -L/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/lib -lmpichf90 -lmpichf90 -lmpich -lpthread -lrdmacm -libverbs -libumad -lrt
/sb/apps/intel/intel_fc_11/lib/intel64/for_main.o: In function `main':
/export/users/nbtester/efi2linux_nightly/branch-ubs-11_1/20090512_000000/libdev/frtl/src/libfor/for_main.c:(.text+0x38): undefined reference to `MAIN__'
+ rc=1
+ '[' -n '' ']'
+ exit 1

The code compiles fine when mpif90 uses gfortran, i.e. when we use mvapich2 compiled with g++/gcc/gfortran.

Steven_L_Intel1 · ‎09-10-2009

admin, the error message may have most of the same words, but it is definitely NOT the same issue. Yours seems to be a simple missing type declaration for MPI_WTIME, plus perhaps a missing main program when you link.

admin2 · ‎09-11-2009

Quoting - Steve Lionel (Intel)

admin, the error message may have most of the same words, but it is definitely NOT the same issue. Yours seems to be a simple missing type declaration for MPI_WTIME, plus perhaps a missing main program when you link.

Do you know why I can compile the program with gfortran but not with ifort? The table below lists what I used to compile the applications below

| mvapich2 | dl_poly | dl_poly finished compiling ? | dl_poly finished linking? |
| gcc/gfortran/g++ | gfortran | yes | yes |
| gcc/gfortran/g++ | ifort | no, error #6404 | N/A |
| ifort/icc | gfortran | yes | no |
| ifort/icc | ifort | no, error #6404 | N/A |

The reason why dl_poly wouldn't link with the icc/ifort compiled mvapich2 and the gfortran compiled dl_poly is understandable because there are references to intel specific calls like __intel_ssee2_strlen and _intel_fast_memcpy that aren't in libgfortran, etc so I ended up getting errors like this during linking:

/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o
/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/lib/libmpich.a(file_openf.o): In function `pmpi_file_open_':
/sb/apps/mvapich2/mvapich2-1.4rc2/src/binding/f77/file_openf.c:132: undefined reference to `_intel_fast_memcpy'

However, the question remains why does gfortran basically have no problems finding the reference to MPI_WTIME but ifort cannot?

% ifort -I/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/include -L/sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/lib -lmpichf90 -lmpichf90 -lmpich -lpthread -lrdmacm -libverbs -libumad -lrt comms_module.f90
comms_module.f90(638): error #6404: This name does not have a type, and must have an explicit type. [MPI_WTIME]
tzero = MPI_WTIME()
---------------^

admin2 · ‎09-11-2009

Quoting - admin@structbio.vanderbilt.edu

I tried the case above with ifort8-10 and got the same error with it not being able to find the reference to MPI_WTIME.

% grep -i MPI_WTIME /sb/apps/mvapich2/Linux2/1.4rc2/x86_64-icc/include/mpif.h
INTEGER MPI_WTIME_IS_GLOBAL
PARAMETER (MPI_WTIME_IS_GLOBAL=1681915912)
EXTERNAL MPI_WTIME, MPI_WTICK
EXTERNAL PMPI_WTIME, PMPI_WTICK
REAL*8 MPI_WTIME, MPI_WTICK
REAL*8 PMPI_WTIME, PMPI_WTICK

TimP · ‎09-11-2009

Yes, it appears that proper inclusion of the header should have taken care of MPI_WTIME, even though this implementation appears to conflict unnecessarily with the standards. So it seems that the include file dependencies are broken, or you may have missed a /Qfpp option in setting up mpif90. Did you check your pre-processed Fortran source?

I would think that you must run gfortran with an mpif90 wrapper configured for gfortran which invokes pre-processing with include paths. You would have the option to set up so that the same pre-processor is invoked ahead of ifort as for gfortran, although that would not normally be a subject for this forum.

Steven_L_Intel1 · ‎09-11-2009

Attach your Fortran source which gets this error.

hero_folomy · ‎01-06-2010

Quoting - admin@structbio.vanderbilt.edu

Does anyone know if this has been fixed in 11.1.046? I've got the same problem but with a different application DL_POLY v3.10 :

http://www.cse.scitech.ac.uk/ccg/software/DL_POLY/

mpif90 -c -ip -O3 comms_module.f90
comms_module.f90(638): error #6404: This name does not have a type, and must have an explicit type. [MPI_WTIME]
tzero = MPI_WTIME()

Do you use Makefile_SRL1 or Makefile_SRL2 ? So, 'Use mpi_module' must be uncommented in 'comms_module.f90'. This remark is written in Makefile_SRL1 and Makefile_SRL2. You should edit comms_module.f90.