string concatenation bug

[knilssen]

I'm compiling a heap of code and none of the lines with // compile. I am using ifort 9.0.031 (tried latest 9.1.032 also). For example, the following code doesnt compile...

open(iunit, file='FILE:'//HDATE(1:datelen), form='unformatted', &
  position='REWIND')

...here is the compiler error message...

fortcom: Error: output.F, line 137: Syntax error, found END-OF-STATEMENT when expecting one of: , )

 open(iunit, file='FILE:'

-----------------------------^

fortcom: Error: output.F, line 138: Unbalanced parentheses

 position='REWIND')

---------------------------^

fortcom: Error: output.F, line 138: Syntax error, found ')' when expecting one of:  ;

 position='REWIND')

---------------------------^

fortcom: Error: output.F, line 138: This name does not have a type, and must have an explicit type. [POSITION]

 position='REWIND')

----------^

...but this code does compile...

character*200 :: fname
fname = 'FILE:'//HDATE(1:datelen)
open(iunit, file=fname, form='unformatted', &
  position='REWIND')

Also, does anyone know how I might rewrite the following to work with ifort? It's the // problem again...

119 format(/,79('#'),//,'Inventory for date = ', A10,1x,A8,/)

[Hirchert__Kurt_W]

Identifying the problem here is easy. Identifying the appropriate solution may be somewhat less so. Your source filename is output.F. By convention, the .F extension is a request for the compiler to invoke C preprocessing on the source lines before compiling them (e.g., if the source contains #ifdef statements to select different variants on the code for different processors). "//" is the beginning of C++ end of line comments. C preprocessing strips those comments from the source before they are seen by the compiler, so the compiler doesn't see the ends of those lines and syntax errors result. Even your example code that does compile wouldn't do what you want it to do -- the "//HDATE(1:datelen)" part would still be gone.

Possible solutions depend on your specific circumstances:

If you don't actually need the C preprocessing, the simplest solution is to change the name of the file from output.F to output.f.

If you do need C preprocessing, but not in all files, it may be possible to retain .F on those files where C preprocessing is needed and switch from .F to .f on everything else. (Obviously, this only works if you don't need "//" in files where you also need C preprocessing.)

In some programs, C preprocessing has historically been used for things that can now be done natively in Fortran. For example, #include lines can be replaced by include statements and use of C preprocessing to implement "global" constants can be replaced with appropriate use of PARAMETER, MODULE, and USE. Switching to the Fortran way of doing things might make it possible to switch from .F to .f.

There are various syntactic tricks one can use to "hide" the "//" from C preprocessing. In your format, there are a number of alternatives to writing "//", including "/ /", "/,/", and "2/". The string concatenation case is not quite as easy. If you are writing in the fixed-form source rules, spaces are largely ignored, so you can insert a space between the two slashes. In free-form (which appears to be what you are using), blanks are significant, so you can't do that, but you can split the "//" operator across a continuation. Instead of writing

A = B // C

you could write

A = B /&
&/ C

(Note that you must have the confirming "&" on the second line, and there must be no spaces between the slashes and the ampersands.) This can get a bit awkward if you have many concatenations in the same statement. In some cases, you can avoid concatenation entirely. Instead of writing

fname = 'FILE:' // HDATE(1:datelen)

you could write

fname(1:5) = 'FILE:'
fname(6:) = HDATE(1:datelen)

Finally, there _might_ be an option on your C preprocessing to turn off its stripping of C++ comments. Whether this is the case will vary from compiler to compiler and preprocessor to preprocessor. I don't know whether the C preprocessing used by ifort has such an option. Perhaps someone from Intel will comment on that aspect. (The problem with this kind of "solution" is that it often is not portable. If a few years from now you have to port your program to a different processor, you may find that the new processor doesn't have a comparable option.)

[knilssen]

thanks for your detailed reply. I'm successfully using the & method to fix the code.
cheers,
Kristian.

[Steven_L_Intel1]

Something isn't right. The Fortran driver calls a Fortran-specific preprocessor which understands // - or at least is supposed to. Please report this to Intel Premier Support.