Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
98 Views

Error #6236 in a code with Macros

Hi,

i am trying to write a code for visualization of the data generated from 3D-MHD turbulent flow (pseudo spectral code)simulations. 

the aim of this code is to create a .avsdat file which could be visualized  using VISIT visualization software.

my code works well on  intel13/composer_xe_2013.1.117, other higher versions of parallel studio give many errors.

i am using fftw/2.1.5_intel13  and mpich-1.2.5.2/   (just incase you want this info)

i have a lot of macros in the first part of the code, then the Program starts ( Code file attached).

 

when i compile this code... i get the following error stating from the the main program avsgen starts (line 153) and the  "error is #6236  A specification statement cannot appear in the executable section" and this continues upto line 192.

then a warning "warning #6717: This name has not been given an explicit type." starts for every variable used in the Macro starting from line 71 and the compilation exits.. informing that there are too many errors.

i have tried all the previous solutions that were specified for this error on this forum.. but could not resolve the problem.

hence this post... to request  a possible solution...

 

P.S.: this code used to work well on Aix, ifort of 2009 (when i was doing my phd) on IBM power 6 machine.. generating the necessary .avsdat files.. 

i now have a 2 node cluster built with 2 processors of Intel® Xeon® Processor E5-2630 v4 on master node and 16 of the same processors in the servant nodes . 

thanking you in advance,

with best regards,

Shiva Kumar. Malapaka

0 Kudos
20 Replies
Highlighted
90 Views

hi ,

i attached 4 files ...  i am able to see only one...

are you able to see all the four files?

shiva kumar.m

0 Kudos
Highlighted
Valued Contributor I
90 Views

Dear Shiva,

the example that you provided is not complete. There are some input files (_param_ most likely, maybe also mpi.h) which are not provided. Hence, there are some declarations missing. In this way, we cannot compile your example.

Best,

    JRR

0 Kudos
Highlighted
90 Views

Dear Juergen,

i have provided the _param_ file  in the  forupload.zip...

mpif.h (thats seen in ns_mod.f90) is a standard file in /mpi/mpich/3.2.1/intel/2018/include/

hope you can use this info...

if you want i can try and attach the mpif.h 

with best regards,

shiva kumar.m

0 Kudos
Highlighted
Valued Contributor I
90 Views

Nope, doesn't compile:

ns_mod.F90(97): error #6404: This name does not have a type, and must have an explicit type.   [MY_PE]
		my_pey = Mod(my_pe(),1)
-----------------------------^
ns_mod.F90(97): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL.   [MOD]
		my_pey = Mod(my_pe(),1)
-----------------------------^
ns_mod.F90(97): error #6363: The intrinsic data types of the arguments must be the same.   [MOD]
		my_pey = Mod(my_pe(),1)
-------------------------------------^
ns_mod.F90(97): error #6404: This name does not have a type, and must have an explicit type.   [MOD]
		my_pey = Mod(my_pe(),1)
-------------------------^
compilation aborted for ns_mod.F90 (code 1)

 

0 Kudos
Highlighted
90 Views

Dear Juergen,

are you doing a Make  (using the part for Linux)...

if you try to compile from command line... there will be issues as far as i know...

shiva kumar.m

0 Kudos
Highlighted
Valued Contributor I
90 Views

The Makefile seem to demand mpiifort which I don't have. Don't you have a minimal example that exhibits the problem? Otherwise you should contact the authors of the code and ask them.

0 Kudos
Highlighted
90 Views

hi Juergen,

i am one of the authors of the code. this code used to work well in 2009. i am now trying to re-use this code.. and getting the specified error and warning messages.

i do not have any simple piece of code showing the same errors... hence i could not provide that...

sorry about that

shiva kumar.m

0 Kudos
Highlighted
Valued Contributor I
90 Views

This sounds like an issue of an extension or standard violation that passed 10 yrs ago, but now compilers are stricter. What about serial compilation? What about other compilers?

0 Kudos
Highlighted
90 Views

unfortunately the code works on ifort alone... thats the primary issue...

0 Kudos
Highlighted
Valued Contributor I
90 Views

That is a strong signal that the code might not be standard-compliant Fortran but is either using some compiler-specific extension or was relying on a compiler-specific bug (e.g. accepts-invalid).

0 Kudos
Highlighted
90 Views

it will take a lot of time to re-do the whole code... to comply with new Fortran compilers... so trying to fix this error..as the rest of the code (that was written in 2009 is doing fine and generating the necessary data !)

0 Kudos
Highlighted
Valued Contributor I
90 Views

You wrote a code that worked ten years ago, which using a lot of preprocessor magic and compiler specifics, you didn't (apparently) continuously maintain your code, and now you expect somebody to debug it for you. What is the exact error message? To which line does it point? Start continuously commenting out more and more parts of your code in order to isolate the error.

0 Kudos
Highlighted
90 Views

Well Juergen.. i have completed all those steps.. and was unable to solve the error... hence i turned for help in this forum.

i presented the full code and attached all the other necessary files including the make file so that any other developer/ expert can see the problem; which is eluding me from some time ; in its full sense and probably  give me a idea/ guide me on how to go about for the solution... 

thats where i stand.. (by the way this problem has been with me for past 1.5 months and i have searched all the old threads but did not find any macros related issues... hence titled the problem as "Error #6236 in a code with Macros"...

shiva kumar.m

0 Kudos
Highlighted
Black Belt
90 Views

Your makefile is broken: the symbol FF is never defined, so it is a null string, as you can see by using the command make -n or make -n ns_mod.o . As Juergen pointed out, your usage of IMPLICIT NONE and not declaring the type of my_pe makes the source file ns_mod.F90 impossible to compile after preprocessing by the GNU cpp preprocessor.

If you wish to take some non-standard Fortran source and pass it through an unsupported macro processor, you are responsible for checking all your user-defined macros and that the output Fortran source is standard-conforming, and to write a makefile that results in the correct commands to be issued. If the macro expansion depends on the quirks of a specific preprocessor (e.g., the AIX preprocessor) to work, you have to do the preprocessing on that platform and move the output file to Linux.

In contradiction to what you said, your problems have no recognizable connection to the version number of the Intel compiler. The makefile does not even cause a Fortran compiler to be called.

It may be time to pause and ask the question: "Is my reliance on macros and preprocessing causing more troubles than the savings (in lines of code)?"

I added integer, external :: my_pe to your ns_mod.F90, and Ifort 19U4 compiled the file fine on Windows with the command 

     ifort /Od /fpp /c ns_mod.F90 .

 

0 Kudos
Highlighted
90 Views

i do not understand .. my_pe is defined on line 46 of ns_mod.F90 and is not anywhere before that...

in the make file i am using the Macros for Linux and there FF  is defined as FF=mpifort

and in my system.. i am able to compile the program and the error is #6236.

but thanks for the link to other forum...

shiva kumar.m

0 Kudos
Highlighted
90 Views

hi mecje4... the same  line Integer, external :: my_pe   is present on line number 46.

the main problem is not in ns_mod.f90

i have trouble in avsgen file...

shiva kumar.m

0 Kudos
Highlighted
Black Belt
90 Views

I do not have the same environment as you do, so I expect that many things will fail because shell expansions and macro expansions will not do what you wanted to happen.

Here is one such bug that I noticed. Lines 76-77 of avsgen1_modified.F90 read:

       Call MPI_Send(localout,nxl,MPI_REAL8,0,0,MPI_COMM_WORLD,mpi_err)\
                Endif;\

When these lines, which are part of a macro definition, get expanded by the Ifort FPP preprocessor, the result is 

       Call MPI_Send(localout,nxl,MPI_REAL8,0,0,MPI_COMM_WORLD,mpi_err)&
                Endif;&

To fix this output, either the terminating '&' of the first line has to be removed, or a preceding ';' inserted. Now you can see the disadvantage of using preprocessors: what are the change that I should make in the preprocessor input file to make these lines come out right?

I recommend that you send the preprocessor output to a file and carefully study that file to see if such errors are present. If, instead, you send the file through the Fortran compiler, the resulting error messages can be quite obscure and mystifying.

0 Kudos
Highlighted
90 Views

yes i dealt with this problem earlier...

and fixed it.. in my environment...

but i see your point of different environments...

as i mentioned in my problem definition... i am getting that error #6236.. and not these..any more.. as i could fix them myself..

shiva kumar.m

 

0 Kudos
Highlighted
Black Belt
90 Views

As I wrote at the end of #18, you should look at the preprocessor output.

The file avsgen1_modified.F90 is missing a terminal '\' at the end of Line 70. As a result, the subsequent lines of the intended macro definition appear as statements in the output. The Fortran compiler has not seen any Subroutine, Function or Program declarations at this point, so it takes those statements as belonging to an unnamed main program. Later, it sees Program avsgen and complains that it sees two main programs.

0 Kudos