gFortran and MAKE

OMG...i need to chose among something again.

Question to SF: is it true Clearwin+ does not work with Equation dot com version ?

Meantime here is another code demonstrating unclear, cryptic, elitist or wrong diagnostics of FTN95 input/output. User-made error of not setting 'filename' as character variable is identified wrong way or hell knows what the message says. FTN95 is very good at fining errors. But what it burbs in its South / Texas accent often simply impossible to decipher

  filename = 'zzzOut.data'
  open(unit=19,file=filename, STATUS='unknown', err=950)
  close (19)
  goto 1000
!......... errors
950 print*,' Error opening file'

1000 continue
end  

The error message says

2. open(unit=19,file=filename, STATUS='unknown', err=950) *** Scalar, default-kind, CHARACTER expression expected for the FILE keyword 1 ERROR [<main program> FTN95 v8.51.0] *** Compilation failed

In this case, I think that the compiler did a fine job. It gave you the line number, and even the clause of the statement on that line that it found to be incorrect.

We could have expected the compiler to complain about the preceding line first, since that line (Line-1) is also in error, since a character expression is being assigned to a real (by implicit naming rules F... is real) variable. Indeed, you may try commenting out the second line of the source code and running the compiler on it again.

I have a suggestion for you. You can get the FTN95 compiler to give you error numbers by using the option /ERR . You can then prepare a text file, say, errlist.txt, with error messages worded as you please, in a language of your choice (North Texan, South Polar, etc.), indexed by the error number. If you type the Windows command

findstr <nnnn> errlist.txt

where nnnn is the error number given by the compiler, you can see your wording of the corresponding message.

hahaha Really drunk logic from both of you, FTN95 + mecesj4. Even not two bugs are here but three: not only FTN95 missed the bug on first line, or reported crazy message on second, it mixed out the order by reporting second line error which was caused by error in the first line.

I'd change each and every error messages if was not translating every english word.

Line 1 is not an errror, but could be compatibility with ftn 4 storing characters in a real variable.

John, looks like not super-duper compatibility too 😃. The filename is 4 bytes, 'zzzOut.data' is 3 times more.

Quoted from JohnCampbell Line 1 is not an errror, but could be compatibility with ftn 4 storing characters in a real variable.

It is an error in Fortran 77 and 95 (and later versions). Quote from 7.5.1.2 of Fortran 95 Standard:

A character intrinsic assignment statement is an intrinsic assignment statement for which variable and expr are of type character and have the same kind type parameter.

See also Table 7.9 of Fortran 95 for type compatibility in <variable> = <expression>

--DUPLICATE POST, Please Delete---

It may be an error in the Standard, but isn't it a common extension supported for backward compatibility ?

If the variable were of type INTEGER, perhaps, but assigning a character constant to a REAL variable would almost guarantee incompatibility, since no mainframes that I know of had IEEE reals, and on PCs we have had IEEE compatibility from the time that the first IBM PC arrived. What the Apple II did, I do not know -- possibly, software emulation on the 6502, which did not have FP instructions.

I didn't have to look very far. CDC Fortran certainly allowed it, as did Pr1me. The following is taken from a Pr1me implementation in 1980's. FTN77 on Pr1me was my first experience of Salford Fortran.

The following was compiled with Pr1me FTN. I think FTN77 also supported this. Lines 2 and 3 were my changes for CDC > Pr1me

C
      IMPLICIT INTEGER*4 (I-N)
      IMPLICIT REAL*8 (A-H,O-Z)
C
C     DRAIN-2D      DYNAMIC RESPONSE ANALYSIS OF INELASTIC STRUCTURES
C
C     A.E.KANAAN AND G.H.POWELL        UNIV. OF CALIF., BERKELEY, 1972
C
      COMMON /CONTR/ NELGR,NEQ,MBAND,NPTH,NPTV,NSTO,JCOL
      COMMON /GENINF/KCONT(10),KELEM(10),NELEM(10),NINF(10),NDOF(10)
     1             ,FCONT(3)
      COMMON /DAMP/ ALPHA,BETA,DT,GAXCTE,CON1,CON2,CON3,CON4,CON5,
     1             C1,C2,C3,C4,C5,C6,C7,C8,C9,C10,C11,C12,BETAO,DELTA
      COMMON /PASS/ IGR,ISTEP,KVARY,NBLOK,KSTAT,KDDS,KM
      COMMON /STOR/ NAVST,NF1,NF2,NF3,NF4,NTST,KODST,KDATA
      COMMON /OUTN/ IPJ,IPE,KNTJ,KNTE,NHOUT,NVOUT,NROUT
      COMMON /WORK/ HED(18),KFORM(2),TITLE(9),W(1972)
      COMMON /INFEL/ IEL,KST,LM(1),DUM(199)
      COMMON /THIST/ITHOUT(10),THOUT(20),ITHP,ISAVE,NELTH,NSTH,NF7,ISE
      COMMON /THISTJ/ITHPJ,NF5,NSTHJ,ISJ
      COMMON /THISTR/ITHPR,NF6,NSTHR,NHR,NVR,LRH1(50),LRH2(50),LRV1(50),
     1       LRV2(50)
C
      DIMENSION A(1)
      DIMENSION CHEK(2),HDAT(3,3),HSTF(2,2),SLOD(2,2)
      DATA CHEK/5HSTART,5HSTOP /
      DATA HDAT/8HEXECUTE ,8H        ,8H        ,
     1          8HDATA CHE,8HCKING ON,8HLY      ,
     2          8HEXECUTE ,8HIF SINGL,8HE BLOCK /
      DATA HSTF/8HSTORED I,8HN CORE  ,
     1          8HSTORED O,8HN TAPE  /
      DATA SLOD/8HLOADS AP,8HPLIED   ,
     1          8HLOADS IG,8HNORED   /
C
C
C     START AND TITLE CARD
C

The code that you show is either Fortran IV or Fortran-66, which did not have LOGICAL or CHARACTER variables, and that is the reason for the appearance of those Hollerith constants in the code.

Allowing <non-character-type-variable> = <character-type-expression> would be an extension, used for allowing old, non-conforming code to continue to work. It is not allowed in standard Fortran 77. Microsoft Fortran 5.0, for example, has this on p.117 of the Fortran Reference Manual, showing the second sentence in blue to signify that it is not standard-conforming:

'Both variable and expression must have type CHARACTER. If the $NOTSTRICT metacommand (the default) is in effect, then a character expression can be assigned to a noncharacter variable...'.

Do not forget about the compiler stability to this bug/feature which made it to become crazy and spew the garbage. Reduce the text to 4 bytes filename = 'zzzO' and the bug either disappear or gets under the carpet. We need rock stable compiler

For the file I part listed, FTN95 with /-IMP compiled many routines with only a few warnings. It did not report an error until line 771.

I think Dan should be prepared to look more extensively for the coding error, then try using SDBG once he gets to creating a .exe.

The following is extracted from drain.lis Using character constants in real*8 is accepted. ( I have not looked at this code in 30 years)

Compiler options in effect:
    ERROR_NUMBERS;INTL;LIST;LOGL;

   0737         SUBROUTINE INAXL (KFORM,TH,GH,TV,GV,GAXH,GAXV,NSTEPS,DT,FACAXH,FAC
   0738        1TMH,FACAXV,FACTMV,IEQFM)
   0739   C
   0740         IMPLICIT INTEGER*4 (I-N)
   0741         IMPLICIT REAL*8 (A-H,O-Z)
   0742   C
   0743   C     SET UP EARTHQUAKE RECORDS
   0744   C
   0745         COMMON /CONTR/ NELGR,NEQ,MBAND,NPTH,NPTV,NSTO,JCOL
   0746   C
   0747         DIMENSION KFORM(1),TH(1),GH(1),TV(1),GV(1),GAXH(1),GAXV(1),
   0748        1          IEQFM(1)
   0749   C
   0750         DATA XPR, YPR /3H X , 3H Y /
   0751   C
COMMENT - 1000: The CHARACTER(LEN=3) constant ' X ' is shorter than the REAL(KIND=2) variable XPR, so will be space-extended 
COMMENT - 1000: The CHARACTER(LEN=3) constant ' Y ' is shorter than the REAL(KIND=2) variable YPR, so will be space-extended 
   0752         IF (NPTH.NE.0) GO TO 20
   0753         DO 10 I=1,NEQ
   0754         IF (IEQFM(I).EQ.2) IEQFM(I)=4
   0755      10 CONTINUE
   0756         GO TO 80
   0757      20 READ (5,30) (TH(I),GH(I),I=1,NPTH)
   0758      30 FORMAT(12F6.0)
   0759         IF (KFORM(1).NE.0) WRITE (6,40) XPR,(TH(I),GH(I),I=1,NPTH)
   0760      40 FORMAT (24H1GROUND ACCELERATIONS IN, A3, 19HDIRECTION, AS INPUT///
   0761        1        5(4X, 4HTIME, 7X, 5HACCEL, 3X)  //
   0762        2        (5(F 8.3, F12.4, 3X)))
   0763   C
   0764         DO 50 I=1,NPTH
   0765         GH(I)=GH(I)*FACAXH
   0766      50 TH(I)=TH(I)*FACTMH
   0767   C
   0768         IF (NSTEPS.LE.0) GO TO 80
   0769         CALL INTPOL (TH,GH,GAXH,DT,NSTEPS)
   0770   C
   0771         IF (KFORM(2).NE.0) WRITE (6,60) XPR,(N,GAXH(N),N=1,NSTEPS)
*** Error 817: Array subscript for first rank of KFORM, 2, is greater than the declared upper bound, 1 
   0772      60 FORMAT (24H1GROUND ACCELERATIONS IN, A3,
   0773        1        37HDIRECTION, AS SCALED AND INTERPOLATED  ///
   0774        2        5(5H STEP, 7X, 5HACCEL, 5X)  //
   0775        3        (5(I5, F12.3, 5X)))
   0776   C
   0777         GA=0.
   0778         DO 70 I=1,NSTEPS
   0779         GAXH(I)=GAXH(I)-GA
   0780      70 GA=GAXH(I)+GA
   0781   C
   0782      80 IF (NPTV.NE.0) GO TO 100
   0783         DO 90 I=1,NEQ
   0784         IF (IEQFM(I).EQ.3) IEQFM(I)=4
   0785      90 CONTINUE
   0786         GO TO 130
   0787     100 READ (5,30) (TV(I),GV(I),I=1,NPTV)
   0788         IF (KFORM(1).NE.0) WRITE (6,40) YPR,(TV(N),GV(N),N=1,NPTV)
   0789   C
   0790         DO 110 I=1,NPTV
   0791         GV(I)=GV(I)*FACAXV
   0792     110 TV(I)=TV(I)*FACTMV
   0793   C
   0794         IF (NSTEPS.LE.0) GO TO 130
   0795         CALL INTPOL (TV,GV,GAXV,DT,NSTEPS)
   0796   C
   0797         IF (KFORM(2).NE.0) WRITE (6,60) YPR,(N,GAXV(N),N=1,NSTEPS)
   0798   C

..ctd

   0789   C
   0790         DO 110 I=1,NPTV
   0791         GV(I)=GV(I)*FACAXV
   0792     110 TV(I)=TV(I)*FACTMV
   0793   C
   0794         IF (NSTEPS.LE.0) GO TO 130
   0795         CALL INTPOL (TV,GV,GAXV,DT,NSTEPS)
   0796   C
   0797         IF (KFORM(2).NE.0) WRITE (6,60) YPR,(N,GAXV(N),N=1,NSTEPS)
   0798   C
*** Error 817: Array subscript for first rank of KFORM, 2, is greater than the declared upper bound, 1 
   0799         GA=0.
   0800         DO 120 I=1,NSTEPS
   0801         GAXV(I)=GAXV(I)-GA
   0802     120 GA=GAXV(I)+GA
   0803   C
   0804     130 RETURN
   0805         END

/OLD will fix this problem. For default options, real = character is accepted.

For John's Drain-2D program (terminate the fragment he gave with a line containing END), using the /ISO option gives

0026)       DATA CHEK/5HSTART,5HSTOP /
*** You cannot use the CHARACTER(LEN=5) constant 'START' to initialise the REAL(KIND=2) variable CHEK

and similar messages for the other instances of initialising REAL variables with Hollerith constants in DATA statements.

Dan may consider trying /ISO, but also be prepared for lots of warnings for minor deviations from standard Fortran.

Quoted from mecej4 Dan may consider trying /ISO, but also be prepared for lots of warnings for minor deviations from standard Fortran. Well or not but /ISO found no problems with my demo above

You are correct. However, when there are multiple errors in adjacent lines of source, many compilers are able to detect only a subset of all the errors in those lines.

Likewise, a compiler may not even scan the rest of the source code of a program unit after finding a severe error.

I have found that when I compile a number of source files with a single command and one the files contains a major error the compiler will terminate the compilation immediately, not even looking at the remaining source files (named in the command line, or implicitly using *.f90), and I have to list the directory to see which files were not compiled.

Quoted from mecej4 Likewise, a compiler may not even scan the rest of the source code of a program unit after finding a severe error. Looks like compiler did not consider this as severe error or as an error at all.

Great would be if cryptic diagnostics messages with 'unwritable' wording substituted with the clear and exact ones other compilers demonstrated above

Dan,

I think I understand your problem with interpreting 'Non-writable' could also have included 'to parameter'. I find that using PLATO and having access to both FTN95 and gFortran does help for interpreting error messages, by easily switching between (three) compilers.

FTN95 message is: C:\temp\forum\dan\dan2.F90(8) : error 304 - Non-writable expression in READ statement C:\temp\forum\dan\dan2.F90(8) : error 52 - Compilation abandoned

gFortran message is: C:\temp\forum\dan\dan2.f90(8) : error - Named constant 'iz' in variable definition context (item in READ) at column 1

Yes, in this case gfortran which may miss many errors compared to FTN95 wins hands down in clarity, you know this comparison here

https://www.fortran.uk/fortran-compiler-comparisons/win32-fortran-compiler-comparisons-diagnostic-capabilities/

• and since years ago this table was made the FTN95 added many more features and diagnostic capabilities (catch trimmed variables at the 72/132 boundary, for example, double declaration of variables in common etcetc. Not listed are mismatch of size of common blocks and many many other errors. And if add useful non-standard and graphics and opengl supporting features this green list of FTN95 will be 100x longer, you perfectly know that, i just mention this for the newbies).

Still to my South Antarctic taste this gfortran error message above could be improved further

*** 'It is forbidden to change PARAMETER iz illegaly used in READ statement on line XXX'

From day one i'm using FTN77-95 i like it finds more errors than any other compiler and many more than i can find myself but hate its error diagnostics language. It is simply unacceptable if the company ever wanted its compiler to be adopted by general public.