error 215 - Invalid expression on left hand side of assignme

Hi group I am getting a compiler error which reads:

'error 215 - Invalid expression on left hand side of assignment'

The error is pointing to the following code:

DOUBLE PRECISION P_W_(30)

P_W_(I2)=DCOS((P(K,I2,6)+ORIE)*D2R)*P(K,I2,7)

Is the problem the variable name ie the last character is an under score?

Thanks for any help.

Is I2 defined as integer?

Yes I have checked that all variables have been correctly defined, I2 is defined as follows:

INTEGER TH,I,J,I2,PCKNUM,ENT_NUM,NUM,H_NUM,ONEH_NUM

Thanks for your comment.

Your expression compiles just fine for me using FTN95 version 7.1.

I would suggest there is an issue with the declaration of one of your other variables. Try systematically swapping these variables for fixed constants until you find it compiles; then you will know which variable is at fault.

Alternatively, could you post a complete program, with a few lines which exhibits the error.

Based on your description of the problem, it looks as if P_W_ is being interpreted as a function in your program. Check all usage of P_W_, as somewhere earlier in your code there will be an array subscript that is type real. If this is the case, this type of error report can be annoying as the cause of the error is an earlier incorrect use of an array subscript and not where the error is being reported.

John

I have listed below part of the routine causing the problem. The include file content can be seen commented out below the include files in the routine.

I have noticed that if I comment out the include file statements and uncomment their content ie declare the variables locally the routine will compile without error.

As listed I get two errors back from the compiler:

1. error 775 - More than one main program encountered

2. error 215 - Invalid expression on left hand side of assignment

           SUBROUTINE ACT_POC(PITCH,X_P,ORIE,BLANK_RAD,PCKNUM,NUM)
   
            INCLUDE 'C:\\Zepf2012\\DR-AWDE\\FTN95_Source\\Includes\\C_ACT_PO.F95'
   

   !\($$\) COMMON /ACTPOC/AP_R,AP_X !\($$\) DOUBLE PRECISION AP_R(0:359),AP_X(0:359)

            INCLUDE 'C:\\Zepf2012\\DR-AWDE\\FTN95_Source\\Includes\\C_P_W.F95'
   

   !\($$\) COMMON /P_W/P_W_,LEAD_ENT,TRAIL_ENT !\($$\) INTEGER LEAD_ENT,TRAIL_ENT !\($$\) DOUBLE PRECISION P_W_(30)

           INTEGER TH,I,J,I2,PCKNUM,ENT_NUM,NUM,H_NUM,ONEH_NUM
           INTEGER CV1,CV2,CV5,CV6
           DOUBLE PRECISION PI,ORIE,DNUM
           DOUBLE PRECISION BLANK_RAD,P,X,BETA,R1
           DOUBLE PRECISION MAX_LD,MAX_TR
           DOUBLE PRECISION X_P,PITCH,POC_PT,N2R
   
           PI = DACOS(-1D0)
           DNUM = DBLE(NUM)
           N2R = PI/180D0*360D0/DNUM
           H_NUM = NUM/2
           ONEH_NUM = 1.5D0*DNUM
   
           DO J = 0,NUM-1
                AP_R(J) = BLANK_RAD
           END DO
   
           ENT_NUM = LEAD_ENT
     1     FORMAT(' ')
           END
   

I have tried placing the COMMON statement after the variable declarations but this does not appear to make any difference.

Thanks for any comments.

Your program compiles fine with FTN95 7.1, with the compiler issuing only warning messages. Which compiler version and which compiler options did you use? The more information that you can give about your programming environment, the more likely will it be that someone can suggest a fix.

The FTN95 compiler tells you source code line numbers along with the error message. Report them, or even better, show a transcript of the compilation session.

Thanks for your comments, below is the compiler transcript:

Compiling file: xx.F95 C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(1) : warning 767 - The argument PITCH has not been used C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(1) : warning 767 - The argument X_P has not been used C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(1) : warning 767 - The argument ORIE has not been used C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(1) : warning 767 - The argument BLANK_RAD has not been used C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(1) : warning 767 - The argument PCKNUM has not been used C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(1) : warning 767 - The argument NUM has not been used C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(14) : error 775 - More than one main program encountered C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(28) : error 215 - Invalid expression on left hand side of assignment C:\Zepf2012\DR-AWDE\FTN95_Source\Includes\xx.F95(32) : warning 21 - Label 1 is declared, but not used Compilation failed.

I have the compiler set to CheckMate Win32 using Plato version 4.64 I am not sure were to look for the FTN95 version?

I now see some important information -- the line numbers. The compiler seems to see the beginning of a new main program on line 14, which suggests to me that there is something odd about the contents of the included files, especially the second one. Please zip up all the files and place them where public access is possible (places such as Dropbox, etc.), because the error may depend on the exact contents of the files, including invisible characters.

Part of the line flagging an error on line 2x got converted to a smiley; please state the line number (which you can see after 'xx.F95(') separately.

You can obtain the version of the compiler by entering the command

 ftn95 /v

in the FTN95 command window.

Make sure you do not have an 'END' statement in your include files as this will end the module in which you have defined the arrays and hence the executable part will not have defined variables. It will also cause the multiple main programs error. Ian

I have posted the source files at:

https://www.dropbox.com/sh/rx7cam71dnhp7nz/AABPTwDXAkD_kRrQKAXda442a?dl=0

There are three files:

xx.F95 // program calling Include files C_ACT_PO.F95 // 1st of two include files C_P_W.F95 // 2nd include file

The F95 compiler version I am using is: 7.10.0

As IanLambley guessed, you have END statements in the included files, which you must remove. To understand why, imagine that the compiler makes two passes over your code. In the first pass, it merges the lines in the INCLUDEd files into the source with the INCLUDE directives. It then compiles the resulting merged file in the second pass. An misplaced END statement causes the compiler to terminate compilation of the current program unit. The subsequent non-comment line is not a SUBROUTINE, FUNCTION or PROGRAM statement, so it is taken to be the beginning of a main program.

There is a second error. The IMPLICIT NONE must occur before other declaration statements. Since you have IMPLICIT NONE in the second included file, when the compiler sees it the compiler has already seen declarations from the first included file and, therefore, complains that it is out of order.

In summary, remove the END statement from the included files, and switch the order of the two INCLUDE directives.

One other thing which might help is to remove the path to the directory containing the include files from the include statement. Plato and the FTN95 plug in for Visual Studio both expect the file extension of the include files to be '.ins'. Placing them in the same directory as the code will then make the code more transportable without editing the source.

There are of other reasons to leave it the way it is.

Regarding my 'guess', it was merely a deduction from the evidence provided. Elementary my dear Watson!

Thank you for that I understand the logic.

The file xx.F95 which I posted is a file which itself is used by a main program and accessed by using INCLUDE, if I understand the application logic for the command then the following would hold true?

In developing the routine xx.F95 I would first remove the END statement in any related referenced INCLUDE files

Compile xx.F95 routine with an END statement to avoid a compiler error and take advantage of compiler debug capability

Then and prior to compiling the main program remove the END statement in xx.F95 as this is also an INCLUDE file

You may ask why all the INCLUDE files, the source was originally written for the Watcom compiler and designed to run with DOS. There are a number of main modules forming the project which share the same source files referenced by using the INCLUDE command. At this stage I am just trying to build working modules prior to porting to a Windows application.

You have some misconceptions regarding the structure of Fortran source files. There are no separate rules for what you can have or not have in include-files. After the include-file contents are inserted into the places where they are invoked by INCLUDE statements, the resulting source code must be correct Fortran source, subject to all the requirements and conventions thereof.

Fortran is a language for programs and projects ranging from tiny to huge. It has strong support for separate compilation of program units, which can then be combined (using a linker such as SLINK.EXE), optionally with inclusion of previously compiled subprograms in object libraries.

I suggest that you move away from COMMON blocks, which are the source of many errors in medium and large programs. Use modules instead. Here is your subroutine, modified to use modules instead of common blocks.

      MODULE C_ACT_PO
         IMPLICIT NONE
         DOUBLE PRECISION AP_R(0:359),AP_X(0:359)
      END MODULE C_ACT_PO

      MODULE C_P_W
         IMPLICIT NONE
         INTEGER LEAD_ENT,TRAIL_ENT
         DOUBLE PRECISION P_W_(30)
      END MODULE C_P_W

      SUBROUTINE ACT_POC(PITCH,X_P,ORIE,BLANK_RAD,PCKNUM,NUM)
         USE C_ACT_PO
         USE C_P_W
         IMPLICIT NONE
         INTEGER TH,I,J,I2,PCKNUM,ENT_NUM,NUM,H_NUM,ONEH_NUM
         INTEGER CV1,CV2,CV5,CV6
         DOUBLE PRECISION PI,ORIE,DNUM
         DOUBLE PRECISION BLANK_RAD,P,X,BETA,R1
         DOUBLE PRECISION MAX_LD,MAX_TR
         DOUBLE PRECISION X_P,PITCH,POC_PT,N2R

         PI = DACOS(-1D0)
         DNUM = DBLE(NUM)
         N2R = PI/180D0*360D0/DNUM
         H_NUM = NUM/2
         ONEH_NUM = 1.5D0*DNUM

         DO J = 0,NUM-1
              AP_R(J) = BLANK_RAD
         END DO

         ENT_NUM = LEAD_ENT
         RETURN
      END SUBROUTINE ACT_POC

Thank you for the advise and assistance from all

As Mecej4 has stated : 'There are no separate rules for what you can have or not have in include-files.'

There is a lot of flexibility in what you place in an include file. I have used an include file list (all.f90), being include 'filex.f90' to simplify the compile and link procedure. It makes the command much simpler, by effectively having only one file for the whole project. Finally: 'FTN95 all /link' builds the project. I use this approach to enable argument list checking or group those routines that I want to include for a /timing option. ( I'd recommend everyone should review the /timing option, as it is very useful for checking performance. Just make sure you exclude some of the low level routines.)

To think of the resulting file, after all includes have been merged gives a good understanding. Include can be any group of Fortran code snippets that suit the purpose.

John

MECEJ4,

When you port code from one compiler to another, you invariably run foul of the extensions allowed by the original compiler, and disallowed by the second. If you allow yourself to be distracted by altering your programming style at this point, you will compound the problem of ever getting the program working with the new compiler.

Watcom's authors took a different line on extensions to the standard than the authors of FTN77, the latter choosing to provide extra system routines (usually, but not always of the SUBPROGRAM@ variety). Watcom, on the other hand, permits extensions to Fortran 77 that look more like later Fortrans.

It's a moot point as to whether the facilities of Fortran 90/95/2003 are always of much benefit to the engineer who programs (as distinct to a computer scientist steeped in conventional theory), especially in the case of the former who just wants his DOS or mainframe software to work on his PC in Windows so that he can go on using it

If I was starting from scratch, and I were decades younger, then I would probably follow your advice to the letter. In this case, and at this point in the process, it may well not be the most helpful suggestion.

Eddie

Eddie, the OP wrote 'At this stage I am just trying to build working modules prior to porting to a Windows application.' That is why I suggested using modules instead of common blocks.

It is reasonable to expect that the OP is going to evaluate any suggestions given here as to suitability, time commitment, usefulness, etc., before adopting them. If OpenWatcom were a viable replacement for the defunct Watcom compiler, and he/she is aware of OpenWatcom, there would have been fewer reasons to consider switching compilers. Given that a switch is being made, there is an opportunity here to make some worthwhile improvements.

Understood, and point taken. However, don't forget that 'module' meant 'separately compilable file' for long before it meant what it does in Fortran 90 et seq.

E