F90 standards for handling Continuation Lines

[TommyCee]

I'm now using IVF (v12.1) and recently got a warning about continuation lines.  I split a long text header by placing '&' at the end and wrapped the line.  It compiles & runs OK but I got a warning message:

warning #5183: Missing ampersand in continued character constant

I have read in an F90 manual the following:
Continuation lines are indicated by an ampersand ( & ) after the code at the end of a line to be continued and before the code on the following line.


But the line I'm breaking is text!  Won't the '&' on the wrapped line be picked up as text?  How would the compiler know to ignore it?  Does it go in a particular column?

[Steven_L_Intel1]

The compiler knows to ignore it because the standard says so. 

"If a character constant is to be continued, an "&" shall be the last nonblank character on the line and shall not be followed by commentary. There shall be a later line that is not a comment; an "&" shall be the first nonblank charcter on the next such line and the statement continues with the next character following that "&"."

There is no required column as long as there is only whitespace before the &.  So for example you might have:

print *, 'This is a long str&
      &ing'

and you'd get: "This is a long string" printed.

I would suggest, though, that a better practice is to always keep character literals on one line and use the concatenation operator if required. For example:

print *, 'This is a long str' // &
    'ing'

You can optionally put a & at the start of the continued line.

[TommyCee]

Thanks Steve.  So I gather that if you're using a Fixed Form Line Lehgth of 132 Columns, and had a text line of (say) 170 characters, the & on the wrapped line would have to appear no farther out than Column 132.

Or would it take text out to C132 and effect a wrap (continuation) if it saw & at (say) C139.

Just trying to understand ...

[Steven_L_Intel1]

Fixed form rules are different.  & at end of line is not used there - you put a non-blank character (other than the digit 0) in column 6.  The statement picks up again at column 7. No & is used, unless you put it in column 6.

What is interesting in fixed form is what happens if you have a source file record that is shorter than the "right margin", say column 60 for normal fixed-form.  What happens to the other 12 positions?  The standard doesn't say and implementations vary.  Ours, by default, honors the short record and does not insert 12 blanks.  Some others do insert 12 blanks.  We have an option, /pad-source (or /Qpad-source), that will do the padding.

Also check out what the manual says about how to write source that is valid for both fixed and free forms.  And lastly, please use free-form source in new development - it will help you avoid needless frustration with coding errors.

[TommyCee]

You always leave me feeling smarter, Steve.  Very interesting.

Actually, what led me down this road was - I thought I was in free-format and somehow I thought I got an error complaining that a line was too long (at least that was my intepretation).  The complaint referenced a long line in which the last character was on Col. 136:

160 FORMAT(' ',///,2X, 'END OF MIXING HEIGHT TAPE REACHED WITHOUT FINDING THE DATE: ',I2, '/', I2,/,2X,'PREPROCESSOR CANNOT CONTINUE')

The messages were:

error #5120: Unterminated character constant
error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: < ) ...

So I wrapped it and compiler errors pointed to long lines further down n the code.

Mind you, this particular code compiled juist fine w/ CVF (but I'm sure youihear that al the tine).

Now you say w/ FFormat, long is good so I wonder what in the devil the issue was w/ this show-stopper.  You really got me scratchin' my head ...

[TommyCee]

Consider this format line (it's a continuation of a line above it):
&       'BI-DAILY MIXING HEIGHT TAPE:',2X,A12,/,2X,'MIXING HEIGHT TYPE:',11X,A5,/,2X,'FOGGING/ICING OPTION:',9X,A12,/,2X,'DRIFT OPTION:',17X,A12,//)

Now I'm getting this associaetd warning message:

warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.

What's up w/ that?

Also, I continue to get these (same) error messages - associated w/ the continuation line above:

error #5120: Unterminated character constant
error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: < ) ...


Again, I never got this conflct w/ CVF.  Any thoughts?

[Steven_L_Intel1]

I don't have enough context to be able to comment.  Please attach a small but complete source file that shows the problem and tell me what command line you used to compile it.  The messages suggest that the compiler thinks you have fixed-form source.

[TommyCee]

Let me say this first:

I had been using Project|Properties|Fortran|Language
Source File Format: Use File Extension (which was the default).

Since you got me thinking, I changed this to:
Use Free Format

Unfortunately, I get the same warnings/errors.

Does that tell you anything?

[Steven_L_Intel1]

No. Something else is happening that you haven't noticed.  Please provide a source and command line and we'll get to the bottom of it.  If you're using a Visual Studio project, make sure you copy the command options from the individual file, as you may have set them differently than for the project.  Or get it from the build log (better).

[TommyCee]

The "command Line" from the Build Log is this:
Compiling with Intel® Visual Fortran Compiler XE 12.1.5.344 [IA-32]...
ifort /nologo /debug:full /Od /free /stand:f90 /warn:interfaces /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c /Qvc10 /Qlocation,link,"C:\Program Files\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\\bin" "G:\SACTI 2\Core Modules\IVF_Builds\Test\Test\SACTI2.f90"

Here is the entire Format Spec. section at the botom of this subroutine .  All warning/errors are associated w/ these lines:

[bash]!    Format Specifictions:
 200 format(A100) !TITLE; was (20A4) -TC
 210 format(2I6,9I2) 
 220 format(5F10.5) 
 230 format(4F10.5) 
 240 format(12F3.2) 
 250 format(12F5.2) 
 255 format(A32)
 260 format(2X,'SURFACE FILE TYPE:',13X,A5) !TC changed 03/05/05; we no longer use mag. tapes
 285 format(1X,'BAD USER INPUT FOR SURFACE FILE TYPE') !TC changed 03/05/05; we no longer use mag. tapes
 290 format(120('*'),/, 2X, a80)                                                      !Added 07/08/12 -TC
 295 format(1x, a100, /, 120('*'))
 300 format(2X,'TOWER TYPE:',12X,A25)                                                     !FORMAT(2X,'TOWER TYPE:',13X,A25)
 325 format(2X,'BAD USER INPUT FOR TOWER TYPE') 
 330 format(2X,'Number Exit Ports:',13X, I2,/,2X,'TOWER HEIGHT (M):', 13X,F6.2,/,2x, 'Exit Port Diameter (M):',7X,F6.2 /, 2X, &
           'Effective Tower Diameter (M):', 1X,F6.2, /,2X,'TOWER HEAT (KW):', 8X,F12.2,/,2X, 'TOWER AIR FLOW (KG/S):',4X,F10.2)
 340 format(' ',/,2X,'INPUT INFORMATION',/,2X,17('-'),/) 
 350 format(2X,'SITE LATITUDE:',16X,F6.2,/,2X,'SITE LONGITUDE:',       &
            15X,F6.2,/,2X,'SITE TIME ZONE:',13X,A8,/,2X,'ROUGHNESS HEIGHT (CM):',7X,F7.2,/,2X,'REFERENCE HEIGHT (M):',8X,F7.2,/)
 360 format(' ',1X,'RECORD STOPPING SWITCH:',6X,I7,/,2X,'RECORD SKIPPING FACTOR:',6X,I7,/,2X,'HOURLY RECORD PRINT LOG:',6X,A12,/2X, &
    &       'BI-DAILY MIXING HEIGHT TAPE:',2X,A12,/,2X,'MIXING HEIGHT TYPE:',11X,A5,/,2X,'FOGGING/ICING OPTION:',9X,A12,/,2X,'DRIFT OPTION:',17X,A12,//)
 365 format(2X,'STABILITY CLASS METHOD:',1X,A11) 
 370 format(//,2X,'MONTHLY CLEARNESS INDEX',/,2X,23('-'),//,3X,'JAN   FEB   MAR   APR   MAY   JUN   JUL   AUG   SEP   OCT   NOV   DEC',/,3X,12('---',3X),/,2X,12(F4.3,2X))
 380 format(//,2X,'TOTAL DAILY SOLAR ENERGY DEPOSITION',/,5X,'(LONG-TERM AVERAGE FOR MONTH)',/,2X,35('-'),//,3X, &
    &        'JAN     FEB     MAR     APR     MAY     JUN     JUL     AUG     SEP     OCT     NOV     DEC',/,3X,12('---',5X),/,2X,12(F5.2,3X))
 390 format(//,2X,'A MIXING HEIGHT TAPE (iMix=2) IS REQUIRED BY THIS CODE VERSION.',/,2X,'IF TAPE DATA IS UNAVAILABLE, USE THE EPRI MAKEMIX UTILITY.')
 415 format(3X,'BAD INPUT FOR URBAN/RURAL MIXING HEIGHT OPTION:',I5) 
 420 format(3X,'BAD SURFACE TAPE DATA AT RECORD NUMBER : ',I5) 
 430 format(//2X,'MET RECORDS READ : ',I8,/,2X,'RECORDS DISCARDED: ',I8,/,2X,'CALM RECORDS:      ',I8,/,2X,17('-'),2X,8('-'),/,2X, 'TOTAL TO NEW FILE: ',I8)

end subroutine PreProcess[/bash]

For reference, L01 above is L3219 in the actual code.  Is this enough code to get a clue?
I realize I'm missing a few "leading" ampersands (&) but that is not the problem here.  I have added & at the begining of a wrapped line and the compiler doesn't even seem to care one way or the other - no change in messages.

[TommyCee]

I should have added this - the following 3 messages apply to L 21 above:

(3239): warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
(3239): error #5120: Unterminated character constant
(3239): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: < ) ...

[Steven_L_Intel1]

I get no errors when compiling this source.  Please attach a ZIP of an actual source file that demonstrates the problem. Better would be to create a small project with just the source and set things up so that you get the error.  Then ZIP the project and attach that.  I won't speculate further until I see everything, not just snippets.

[Steven_L_Intel1]

The warning 5268 is valid as the standard allows free-form source lines of up to 132 characters only.  We support much longer.  But the errors you're getting are caused by something else, which you have not yet shown.

[jimdempseyatthecove]

Tommy,

I cannot answer for Steve as to if the file you inserted into your response (with pencel) is useful or not. The web based tool will at time change your text. Steve requested that you "attach" a file. There is an "Add Files" button that you can use to upload a file. Choose further to insert link to your uploaded file as opposed to inserting the contents of the file (I think you still have two choices after upload).

Jim Dempsey

[Lorri_M_Intel]

Do you have a directive in your source that sets it to fixed form?  Some options are

$NOFREEFORM
  or
!DEC$ NOFREEFORM

              --Lorri

[TommyCee]

This is in response to several replies (not perhaps in order) - all appreciated.

btw, it would be nice when replying to a thread one could see the thread (as in many forums) - but the thread is not visible.  I can only see Lorri's.  (frown)

• Steve asked several times to attach the source code.  Great suggestion.  I wish I could but unfortunately it's propietary.  What a conumdrum.  I will be glad to send you the code privately, Steve.

• I did attach the file to Premier Support and the response was sorta like Steve's (it complied fine), except the person turned off Warn for Non-standard Fortran (/stand:F90)!  His suggestion to me was to set Warn for Non-standard Fortran (/stand:F90) to 'NO'.  IMHO (and this was my reply back to him):  Of course I know I can do that to make the compiler much more forgiving and tolerant of code.  But my purpose was to let the compiler guide me to make the code perfectly F90 compliant.  To set this switch to 'No' is cheating.

• As to Lorri's reply (Hi Lorri - long time!), that's a reasonable suspicion.  Makes perfect sense,  except it ain't fixed format.  Under Project Properties|Fortran|Language, the switch is Use Free Format (/free), which is indicated in the command line I posted upstream in this thread.

[Steven_L_Intel1]

What I do in the forum is right click on the link to the thread (while replying) and open it in a new tab or window.

You pasted a bunch of code and said the problem was in those lines.  You should be able to make a separate source file out of those lines (perhaps add a SUBROUTINE line) and reproduce the problem.

The setting for the warning will not affect whether you get the errors you have reported here.

What is the Premier Support issue number?  I can't find it by your email address here.

[Steven_L_Intel1]

I found Tom's Intel Premier Support issue and verified that with the 12.1 compiler and standards checking enabled, the source fails to compile.  This is fixed in the 13.0 compiler due out in a couple of weeks.