free + fixed form continuation lines

[David_Mccabe]

Hi there,

I am working on a codebase which contains a large number of include files which are used in both free-form and fixed-form source files.  These include files contain continuation lines which use the following convention:

an "&" is placed on the upper line after the 72nd column, and an "&" in column 6 on the lower line as follows:

[fortran]

       COMMON /APMISC9/ AVAIL3TC, AVAILDES, AVAILSS, AVAIL3D, AVAILSW,   &

      &                 AVAILSMP, APCUSTIN

[/fortran]

Previously this worked fine for free and fixed form but since updating to the latest Intel Visual Fortran Composer I recieve the following error:

"error #5082: Syntax error, found '&' when expecting one of: %FILL <IDENTIFIER>"

Is there a way to avoid this error without editing the source?

[TimP]

This is a well accepted way of dealing with 72-column f77 standard fixed form as well as free form. It won't work with any of the extended length fixed form options. If there is a problem with current compilers, a small example to reproduce it should be submittted.

[jimdempseyatthecove]

cDEC$ FREEFORM include 'FreeFormHeader.fi' cDEC$ NOFREEFORM -------------- Steve, if you read this Suggest adding (such that the directives can be placed in the include file) cDEC$ PUSH(FREEFORM), FREEFORM ! push state of freeform, set to freeform COMMON.... cDEC$ POP(FREEFORM) ! pop state of freeform Also consider push/pop for other changeable states. Note, although you could use FPP macros to do this in the .f90 and .f files you could not use FPP in the FORTRAN INCLUDE files since fortran include occurs post FPP (though you could use FPP #include files). Jim Dempsey

[David_Mccabe]

Thanks for the swift response, I still don't see anything out of place in the project properties dialog. I have attached an example with fails to build for me. Project property, "Fixed Form Line Length" = "72 Colums" = inherit from project defaults Compiler: Intel(R) Visual Fortran Composer XE 2013 Integration for Microsoft Visual Studio* 2010, 13.0.3588.2010

[David_Mccabe]

the following seems a compiler independant and legal alternative: [fortran] COMMON /APMISC9/ AVAIL3TC, AVAILDES, AVAILSS, AVAIL3D, AVAILSW COMMON /APMISC9/ AVAILSMP, APCUSTIN [/fortran] Jim's idea of returning the freeform state back to previous value would be helpful

[Steven_L_Intel1]

There are a couple of problems with the include file you attached. One is that some of the lines begin with a tab character - this is counted as a single column for the purpose of line length even if it displays as multiple blanks. The second is that the & at the end of the lines is in column 72 - it needs to be in column 73 for this to work. As for Jim's suggestion - I'll note that the existing directives operate sort of like this already in that the effect of a [NO]FREEFORM directive expires at the end of the source file in which they appear, implicitly "popping" when the compiler goes back to the file that did the include.

[David_Mccabe]

The test case I uploaded works fine with those corrections however, I see no problems with our main codebase which still fails to build. Please see the screen dump.

[jimdempseyatthecove]

I notice you have a comment ... keep LMTYPC=MMFPRO in MacroFlo By chance/mistake would any of your variable names in the affected area be FPP macro names? If so, this may change the line length in accordance with change in number of characters in substitution. Jim Dempsey

[jimdempseyatthecove]

A few lines above (line 128?) you use LMTYPC on an integer*4 declaration, which the comment on line 133 states LMTYPC is a macro. I suggest you break-out variables used as macro from any line with continuation. e.g. on line 128 remove the {whitespace}&, and on 129 replace &{whitespace} with integer*4. This should be easy enough for a test. Recompile and see if the errors in PROFIL.INS begin later than line 128. If it does, then look for other instances of FPP macro name in statement with continuation. Jim Dempsey

[Steven_L_Intel1]

If you can provide a compilable test case, I'd be glad to look at it.

[David_Mccabe]

I am not able to replicate the problem in a test case. I will rollback the compiler version for now and try again later. Jim: there is a lot of code which has been commented out in our source. We don't run any macros/preprocessor Thanks

[jimdempseyatthecove]

You might also try inserting cDEC$ FREEFORM at the top of the affected headers. Also, then in VS editor, do Ctrl-A to select all, then look at your end of line &'s to see if any white space follows. Jim Dempsey