Welcome to our forums
I think i asked that question before...
common /aaaa/ bbbbbbbbbbbbbbbbbbb, ccccccccccccccccccccccccccc
* ddddddddddddddddddddddd
Must be ERROR.
Damn, made today 3 times this same error. And despite using /NO_TRUNCATE (which served well so far against not using 'implicit none') the error was not reported
Dan,
I am not sure what your error is ? I compiled the following file (named dan.for) using ftn95 dan.for /-imp /lis /xref and got the following response:
{dan.f90}
common /aaaa/ bbbbbbbbbbbbbbbbbbb, ccccccccccccccccccccccccccc
* ddddddddddddddddddddddd
!
real aa
!
AA = 1
END
{dan.xrf}
Silverfrost FTN95/WIN32 Ver 7.10.0 Cross reference information for dan.FOR Tue Nov 17 14:32:46 2015
Line numbers followed by ~ refer to include files.
Line numbers followed by * represent variable assignments and label definitions.
Generating information for SUBROUTINE MAIN@
REAL :: AA
5, 6*
REAL, {Offset 0 in Common/AAAA/} :: BBBBBBBBBBBBBBBBBBB
3
REAL, {Offset 4 in Common/AAAA/} :: CCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDD
3
{dan.lis}
Silverfrost FTN95/WIN32 Ver 7.10.0 dan.FOR Tue Nov 17 14:32:46 2015
Compiler Options in Effect:
COLOUR DELETE_OBJ_ON_ERROR ERROR_NUMBERS INTL LIST LOGL MINIMISE_REBUILD NO_QUIT
NON_STANDARD SINGLE_THREADED XREF
0001 common /aaaa/ bbbbbbbbbbbbbbbbbbb, ccccccccccccccccccccccccccc AT 0
0002 * ddddddddddddddddddddddd AT 0
0003 ! AT 20
0004 real aa AT 20
0005 ! AT 20
WARNING - 242: Variable AA has been given a value but never used
0006 AA = 1 AT 20
0007 END AT 30
0008 AT 30
0009 AT 30
End of Compilation - Clocked 0.05 seconds
The following also works. Is your problem that the variable name extends over 2 lines and terminates before column 72 on the first line ? (My solution always is to provide a list of valid names and use /imp.)
common /aaaa/ bbbbbbbbbbbbbbbbbbb,
* ccccccccccccccccccccccccccc
* ddddddddddddddddddddddd
!
real aa
!
AA = 1
END
ps : These do not compile with Ver. 8.00 beta.14 if /xref is selected; giving an Access Violation
To show the example the comma at the end of the line was intentionally missing. As a result of forgotten comma, instead of two variables ccccccccccccc and dddddddddd, the new variable is created cccccccccccccdddddddddddd
The point was that this kind of line continuation when the name starts on one line and is continued on another should not be permitted because this is most stupid idea - to break the variable names such way. (for example because if you will search for this two line variable in editor you will not find it. Also in human syntax we use '-' sign to indicate that the word is continued on the next line. Fortran should follow this to be closer to natural language rules to reduce potential errors. Such errors are rear of course but in the large code the chance to have it increases which may break the entire code).
This way of continuation is error prone if you do not use 'implicit none'.
My experience says that i often miss comma specifically when in the hurry which is my regular state. Such errors sometimes not easy to find.
This is an addition to the discussion which ended with very handy option NO_TRUNCATE which treats now similar error when the variable hits 72-character limit and the new variable is created as a sum of two lines.
Interesting if someone here uses this way of continuation of variable names. If no one do that then we should do something with it. May be offer additional switch to guard codes from potential errors.
Dan,
While what you describe looks like lunacy to me, but my guess is that it is standard-conforming. I think if you looked at some source codes from the 60s and 70s you might find examples there, as you needed to think well ahead when using a card punch! (Although they would be only a few characters on each line).
If it wasn't in COMMON, FTN95 would tell you it was defined but not used. Don't you cut'n'paste COMMON or put it in an INCLUDE?
Are you now a convert to IMPLICIT NONE? I feel like I lost my last friend in the whole world!
Eddie
No i did not convert to implicit none.
My point and wishes here were to make Fortran more bullet proof and future proof. We got a lot of knowledge since punchcard Fortran. If i print my code on punchcards the pile would be 50 meters high. Just reading this would cause many input errors. If we'd still use punchcards such codes like mine would be impossible, they'd die under entropy of own faults.
So i am trying to extend the life of my code beyond that, beyond future 1 Million lines when i combine my 32bit codes into one 64bit one and still get it manageable. That implies attention to small details in syntax, in depth of diagnostics, in quality of compiler implementation etc...64bitness is also part of futureproof.
Fortran must be not only fast and naturally simple but also reliable to make a heartbeat controllers in it.
I feel that if i'd chose any other compiler then this one i'd stop my massive code development long ago. And if it became 64bit 10 years ago, then it would be a Godzilla among Fortran codes by now. And if 20 years ago Salford developed the compiler for supercomputers as i asked them at that time (having access to all 5 'top5' supercomputers in the world at the same time) the only my code wouldn't do is dishwashing 😃