I was really happy to find this in readme as one of the goals: "Produce an alternative FORTRAN front-end for open-source compilers.".

After cloning and running make, I do the following:

$ cat tests/programs/array.f
      PROGRAM array
        INTEGER a(16)
        INTEGER b(5)
        b = a(1:5) * 5
      END PROGRAM array
$ ./ofc --parse-tree tests/programs/array.f
      PROGRAM array
        INTEGER a(16)
        INTEGER b(5)
        b = a(1:5) * 5
      END PROGRAM array

Warning:tests/programs/array.f:2,16:
   Variable 'a' read but never written
        INTEGER a(16)
                ^
Warning:tests/programs/array.f:3,16:
   Variable 'b' written but never read
        INTEGER b(5)
                ^
$ 

Is the output of ofc --parse-tree intended just for humans? Or, can the parse tree be output also in some more program-friendly format? In other words, is there a way to print the parse tree in any other way than as source code?

I find it hard to believe that actually one options of the parser is to... print the source code.

Just in case I was misunderstood: I don't mean to complain, I'm just looking for a way to use ofc as a parser for a source-to-source compiler I'm working on. Can I use ofc for that in its current form?

Just a minor specification (non-executable-code) bug, but it caught a typo in an INCLUDE file.

Much of our codebase is compiled with an option making SAVE the default (for local variables/arrays at least; not sure about the affect on COMMON blocks, though IME that really makes no difference in code generation).

So, for (implicitly) RECURSIVE procedures, we use the AUTOMATIC statement, akin to SAVE but having the opposite effect.

This yields:

Use of AUTOMATIC keyword is non-standard and deprecated, ignoring

While it's possible all the compilers we'll use on ofc's output will support the same option to make SAVE default, ideally ofc would offer a similar option and convert the code by eliminating AUTOMATIC (as it now apparently does) and inserting SAVE statements for whatever is appropriate -- which, superficially, would include all local variables/arrays not declared AUTOMATIC, but could be smart enough (using flow analysis) to avoid simple cases where it's obviously not needed.

If that's too difficult (for now), at least please do optionally preserve AUTOMATIC in the output, or the resulting code likely won't work when recursion actually happens at run time. (This might also deserve to be the default.)

Further, use of any AUTOMATIC keyword implies the programmer either intended the possibility of recursion or worried that a sufficiently large amount of storage would unduly increase the size of the executable (and VM) even when the procedure wasn't active -- yet wasn't worried about stack.

Let's go with the former case and (perhaps optionally) support adding the RECURSIVE keyword on all such procedures (maybe optionally on all procedures, perhaps unless a given procedure can be shown to not possibly need it).

E.g.:

$ cat > decl.inc
      INTEGER FOO
      PARAMETER (FOO = 2)
$ cat decl.inc
      INTEGER FOO
      PARAMETER (FOO = 2)
$ ofc --sema-tree decl.inc > decl-new.inc
$ cat decl-new.inc

This isn't a problem for our Fortran compilers (nor gfortran, obviously) -- even with the command-line options we use (to get F77-like behavior and extensions).

But it's a problem for at least one of the tools we use, f2c, to automatically generate C .h files. (This conversion doesn't support STRUCTURE, thankfully, so we needn't worry about TYPE.)

Also, ofc itself can't handle these when reading back the input.

Can ofc support an option (perhaps on by default for .inc files) to generate the older-style declarations (separate INTEGER and PARAMETER, ditto anything else like that)?

Referring to the code at #29:

The warnings:
Warning:volterra_627.f:711,25:
Incompatible argument type (REAL) in SUBROUTINE call, expected FUNCTION.
CALL VE1(K, G, FX, M1, KA, NEPS, RELERR, ABSERR, XL, X, XOUT,

and
Warning:volterra_627.f:2649,14:
Incompatible argument type (REAL) in SUBROUTINE call, expected SUBROUTINE.
10 CALL DE(F, G, FX, NEPS, NEQN, KA, BMA, Y, T, TOUT, RELERR,

indicate that passing function and subroutine names as arguments is not properly recognised.

Despite man page suggestions to the contrary, 'dprintf' is not generally available as a global definition on Unix (and specifically not on Solaris/Sparc). The OFC function 'ofc_colstr_fdprintf' (defined in 'colster.c' and called from 'main.c') uses 'dprintf' in its implementation, and so OFC did not at first link on Solaris/Sparc.

The good news is that, after implementing 'dprintf' (using 'vsprintf' (to write to a fixed-size buffer, which is not ideal, but "good enough") and 'write' to write the buffer to the (opaque integer) file handle, OFC links and runs on Solaris.

Note also that, although 'ofc_colstr_fdprintf' takes a file handle, its only call passes in 'STDOUT_FILENO', in which case the call is equivalent to 'printf'. If there is a deeper purpose to the implementation taking a file handle (which at present is never used except to be 'stdout') the reason is not obvious and should be documented. (More generally, the code should be documented, but that's a separate Issue).

Currently we don't check that EQUIVALENCE statements are valid, and compatible with COMMON block rules.
To do this we'll need to generate a memory map, and error on any unresolvable conflicts.

E.g. note that sfunc is not declared INTEGER in the output here, as well as there being a spurious warning about dummy not being used (in fact, it is used as a parameter in sfunc):

$ cat sfunc.inc
      integer dummy, sfunc
      sfunc(dummy) = dummy + 1
$ ofc --sema-tree sfunc.inc > sfunc-new.inc
Warning:sfunc.inc:1,14:
   Variable 'dummy' declared but not used
      integer dummy, sfunc
              ^
$ cat sfunc-new.inc
        INTEGER :: dummy
        sfunc(dummy) = dummy + 1
 $

The double-colons are unncessary and will prevent older tools from reading the resulting output (mainly a problem for .inc files). E.g.:

 $ cat decl.inc
      INTEGER FOO
      PARAMETER (FOO = 2)
$ ofc --print-f77-parameter --sema-tree decl.inc > decl-new-2.inc 
$ cat decl-new-2.inc
        INTEGER :: FOO
        PARAMETER (FOO = 2)
$

Several issues with the output of OFC on the attached source file. Also included the output of the analysis.

The line numbers are incorrect. For instance:

Warning:volterra_627.f:741,15:
Implicit cast may be lossy.
ACC = -DLOG10(DABS(DIFF))

In the original source file this statement appears on line 371.

The warning about "END":

Warning:volterra_627.f:811,6:
Implicit PROGRAM statement
END
^
seems related to line 406 - the end of the main program.

Could it be that the line number reported is actually twice the line number - 1?

Could it be that this has to do with the fact that the source file contains Windows' CRLF line endings, while the program was run on Cygwin?

output.zip

Referring to the code at #29:

The warning:
Warning:volterra_627.f:415,39:
Variable 'U' read but never written
DOUBLE PRECISION RELERR, ABSERR, U, DIFF, K, G, FX

indicates that the analysis of read/write actions is not quite waterproof: the variable in question is set in the subroutine VE1 (line 740 of the source file). Indeed it is not set in the calling program unit.

I get "Literal too large for compiler" error from the following contexts:

Error:./mma114.f:79,22:
   Literal too large for compiler
      ZDC( IDX4+J ) = (0.0,0.0)
                      ^

Error:./mma403.f:91,29:
   Literal too large for compiler
      IF ( ZC( INDXBV ) .EQ. 0.0D0 ) GO TO 1450
                             ^

Do you have an idea what this error means?

Given an input program with a statement such as:

write(6,*)'enter something (current "',something,'")'

ofc -s ... produces:

WRITE (6, *) "enter something (current \"", something, "\")"

Note the change from the string being quoted via apostrophes to being quoted by double quotes. ofc seems to recognize the need to quote the double quotes in the output, but it does that by prefixing them with backslash -- a C-ism offered by many Fortran compilers -- rather than the standard-conforming doubling of the double quote (a "quadquote", perhaps?).

I.e. the output should be:

WRITE (6, *) "enter something (current """, something, """)"

E.g.:

$ cat nothing.f
      program nothing
      print 10
 10   format('there')
      end
$ ofc --sema-tree nothing.f
Error: Failed to print statement: IO_PRINT
Error: Failed to print stmt list
Error:nothing.f:
   Failed to print semantic tree

ofc doesn't recognize that a RECORD statement specifying a STRUCTURE that has initial values has in fact been written. E.g.

$ cat init-struct.f
      PROGRAM TEST
      STRUCTURE /BBIT_AVOID_SETINTELPROD_IN_OFFLINE/
        INTEGER*4      ID       /256914/
        INTEGER*4      TYPE     /5/
        INTEGER*8      DEFVAL   /0/
        CHARACTER*(34) NAME
     +      /'bbit_avoid_setintelprod_in_offline'/
        LOGICAL*1      NIL      /0/
      END STRUCTURE
      RECORD /BBIT_AVOID_SETINTELPROD_IN_OFFLINE/
     +        BBIT_AVOID_SETINTELPROD_IN_OFFLINE_R
      PRINT *, BBIT_AVOID_SETINTELPROD_IN_OFFLINE_R
      END
$ ofc -s init-struct.f > init-struct-new.f
Warning:init-struct.f:11,14:
   Variable 'BBIT_AVOID_SETINTELPROD_IN_OFFLINE_R' read but never written
      RECORD /BBIT_AVOID_SETINTELPROD_IN_OFFLINE/
     +        BBIT_AVOID_SETINTELPROD_IN_OFFLINE_R
              ^
$ cat init-struct-new.f
      PROGRAM TEST
        IMPLICIT NONE
        TYPE BBIT_AVOID_SETINTELPROD_IN_OFFLINE
          SEQUENCE
          INTEGER*4 :: ID = 256914
          INTEGER*4 :: TYPE = 5
          INTEGER*8 :: DEFVAL = 0
          CHARACTER(34) :: NAME = "bbit_avoid_setintelprod_in_offline"
          BYTE :: NIL = 0
        END TYPE BBIT_AVOID_SETINTELPROD_IN_OFFLINE
        TYPE(BBIT_AVOID_SETINTELPROD_IN_OFFLINE) ::                     &
     &BBIT_AVOID_SETINTELPROD_IN_OFFLINE_R
        PRINT *, BBIT_AVOID_SETINTELPROD_IN_OFFLINE_R
      END PROGRAM TEST
$

I suggest adding the topics fortran, fortran77, compiler in the About section at https://github.com/CodethinkLabs/ofc

when
make install
show error:

gcc-8 -O3 -Wall -Wextra -Werror -std=gnu99 -MD -MP -I include   -c -o src/sema/typeval.o -g src/sema/typeval.c
src/sema/typeval.c: In function 'ofc_sema_typeval_cast.part.4':
src/sema/typeval.c:1398:11: error: 'tv.<Ucc78>.integer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    if ((tv.integer < -128)

I checked the typeval.c file, maybe
typeval->type->type not equal to any of case, under
switch (typeval->type->type)

A Fortran main program unit needn't being with a PROGRAM statement, yet ofc seems to require one.

E.g. this should work:

      END

Instead, this is printed:

Error:ofc-tests/programs/end.f:1,6:
   Expected end of input
      end
      ^

If a PRINT statement precedes the END statement, ofc prints this instead of accepting it:

Error:ofc-tests/programs/print.f:1,6:
   Unexpected executable statement in scope.
      print *, 'this should not work'
      ^

Would be good to be able to have an option to do just this, as we have some code that uses the archaic TYPE statement, but we do want to see (some) other warnings.

@ben-brewer-codethink We got another failure with Clang:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_ofc/ofc/work/compwrap/cc/usr/bin/clang -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -O3 -Wall -Wextra -Werror -std=gnu99 -MD -MP -I include -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk  -c -o src/parse/call_arg.o src/parse/call_arg.c
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_ofc/ofc/work/compwrap/cc/usr/bin/clang -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -O3 -Wall -Wextra -Werror -std=gnu99 -MD -MP -I include -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk  -c -o src/parse/common.o src/parse/common.c
src/prep/unformat.c:495:11: error: variable 'row' set but not used [-Werror,-Wunused-but-set-variable]
        unsigned row, pos;
                 ^
src/prep/unformat.c:628:11: error: variable 'row' set but not used [-Werror,-Wunused-but-set-variable]
        unsigned row, pos;
                 ^
fatal: not a git repository (or any of the parent directories): .git
2 errors generated.
fatal: not a git repository (or any of the parent directories): .git
make: *** [src/prep/unformat.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes.  Stop.
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_ofc/ofc/work/ofc-1" && /usr/bin/make -j8 -w all CC="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_ofc/ofc/work/compwrap/cc/usr/bin/clang" CXX="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_ofc/ofc/work/compwrap/cxx/usr/bin/clang++" OBJC="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_ofc/ofc/work/compwrap/objc/usr/bin/clang" OBJCXX="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_ofc/ofc/work/compwrap/objcxx/usr/bin/clang++" INSTALL="/usr/bin/install -c" 
Exit code: 2

Referring to the code at #29:

The warnings:

Warning:volterra_627.f:413,15:
Variable 'K' read but never written
EXTERNAL K, G, FX
^
Warning:volterra_627.f:413,18:
Variable 'G' read but never written
EXTERNAL K, G, FX
^
Warning:volterra_627.f:413,21:
Variable 'FX' read but never written
EXTERNAL K, G, FX
^
indicate that the EXTERNAL statement is not properly treated.

This code is actually valid:

Error:./ktshld.f:121,30:
   Invalid initializer
      DATA    BLANK , NAME  / 4H    , 4HTRSH, 4HL     /
                              ^

because Hollerith constants may have whitespaces, and they are unquoted. This is one spectacular piece of Fortran, which exists to confuse the whitespace-based tokenizers.

Does ofc have a way of exporting this form of the parsed tree:

https://en.wikipedia.org/wiki/Static_single_assignment_form

If so, what data encoding is used?

When I tried to compile the code using GCC 5.3.0 on Cygwin, I got error messages about the use of stdin and stdout as component names in stmt.h

I solved that by appending an X to those names (also in read.c and write.c). Then it worked.

For the attached file I get:

Error:./ascm04.f:17,21:
   Incompatible types in initializer
      DATA SLASH   / 1H/       /

ascm04.f.gz

When compiling with GCC 8.1.0 on Ubuntu and 8.3.0 on Mac, via the default make command, I get the following errors (coming from warnings being treated as errors):

cc -O3 -Wall -Wextra -Werror -std=gnu99 -MD -MP -I include   -c -o src/./file.o src/./file.c
src/./file.c: In function ‘ofc_file_get_position’:
src/./file.c:288:8: error: this statement may fall through [-Werror=implicit-fallthrough=]
     if (file->strz[i + 1] == '\n') i++;
        ^
src/./file.c:289:4: note: here
    case '\n':
    ^~~~
cc1: all warnings being treated as errors

and:

cc -O3 -Wall -Wextra -Werror -std=gnu99 -MD -MP -I include   -c -o src/sema/typeval.o src/sema/typeval.c
src/sema/typeval.c: In function ‘ofc_sema_typeval_cast.part.4’:
src/sema/typeval.c:1396:11: error: ‘tv.<Uf390>.integer’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    if ((tv.integer < -128)
         ~~^~~~~~~~
src/sema/typeval.c:1321:12: error: ‘tv.<Uf390>.integer’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     if ((tv.integer < -imax)
          ~~^~~~~~~~
cc1: all warnings being treated as errors

Workaround is to run FLAGS="-Wno-implicit-fallthrough -Wno-maybe-uninitialized" make but in my opinion it's better to fix it, so I've prepared a pull request #44 for that.

In issue #14 , it is mentioned that COMMON and EQUIVALANCE blocks in Fortran complicate the export of an SSA tree.

On the Fortran COMMON/EQUIVALENCE issue, there exists a (light, wrapper) script that runs the Sun f90 compiler with the -Xlist flag. That flag gives, for each parsed file, a listing of what COMMON blocks are used, the offset into that block, and, if the usage is via an EQUIVALENCE, what the nominal reference is. The tool is Sun-only, but is very nice.

Could OFC output similar information?

E.g.:

$ cat > external.inc
      EXTERNAL FOO
$ ofc --sema-tree external.inc > external-new.inc
$ cat external-new.inc
$

But it's important to preserve these, so a code typo like R = FOO (instead of R = FOO()) is caught.

Note that an accompanying declaration, such as INTEGER FOO, is also swallowed (not emitted).

I'm installing OFC in an upcoming release of the Sourcery Institute Linux virtual machine. Cloning using the command in the OFC README.md returns the error message below

$ git clone https://github.com/CodethinkLabs/ofc.git --recursive
Cloning into 'ofc'...
remote: Counting objects: 9923, done.
remote: Total 9923 (delta 0), reused 0 (delta 0), pack-reused 9923
Receiving objects: 100% (9923/9923), 1.92 MiB | 1.10 MiB/s, done.
Resolving deltas: 100% (8030/8030), done.
Checking connectivity... done.
Submodule 'tests' ([email protected]:CodethinkLabs/ofc-tests.git) registered for path 'tests'
Cloning into 'tests'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of '[email protected]:CodethinkLabs/ofc-tests.git' into submodule path 'tests' failed

which presumably explains why make test fails with the following error message:

make FRONTEND=/home/rouson/Desktop/Builds/ofc/ofc  -C tests test
make[1]: *** tests: No such file or directory.  Stop.
Makefile:83: recipe for target 'test' failed
make: *** [test] Error 2

Any advice?

gfortran supports this option. E.g.:

init.f contains:

      subroutine init
      integer i
      character*10 str
      print *, 'i=',i,' str=',str,' str(1:1)=',ichar(str(1:1))
      end
      program try_init
      call init
      end

$ gfortran -W -Wall -o init init.f
$ ./init 
 i=       32608  str= str(1:1)=           0
$ gfortran -finit-local-zero -W -Wall -o init init.f
$ ./init 
 i=           0  str= str(1:1)=           0
$

At the very least, this option would prevent any warnings about local variables/arrays not being initialized (except where they clearly become undefined, at some point in the code flow, and are then referenced).

Ideally, suitable DATA or equivalent would be added to the converted output so -finit-local-zero (or similar option in another compiler) would not be needed, and the code somewhat clarified.

"Symbol name begins with langauge keyword" (please fix the typo in the penultimate word!) warnings are occurring for names beginning with "TO".

I'm unaware of "TO" being a Fortran language keyword, except possibly in "GOTO" when spelled out as "GO TO", though I can't recall whether free-form source allows that form.

Regardless, in this case it is hardly a problem that the name begins with "TO", assuming there's no statement that begins with "TO".

Generally, I'm not sure what the goal is with this sort of warning. It makes some sense to warn about names like "REALPERSON", since that could be mistaken for "REAL PERSON" in FORTRAN 77 (fixed form).

But to warn about "EXIT" in e.g. "CALL EXIT(0)", when the name refers to a subroutine and so cannot start a statement (nor be assigned to within the subroutine itself, unlike function program units), seems excessively noisy.

In that case, however, I don't know whether the semantic information (as to whether the name refers to a subroutine or some other "innocuous" thing like, say, a common block) is available at the time the diagnostic is generated.

src/./file.c:289:5: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
                                __attribute__ ((fallthrough));
                                ^
1 error generated.

Log: https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/129373/steps/install-port/logs/stdio

I tried compiling a .f that contained only a SUBROUTINE program unit, and got this complaint:

Warning: Unused SUBROUTINE 'subrname'

This seems surprising, because it is certainly normal for a .f to not contain an entire program, but rather one or more subroutines (and functions, though I haven't yet tried that) that aren't referenced (used, called) by any code in just that module.

The expectation is that they'll be called by one or more programs that link in the object files that result from compiling such modules.

Is there an option to suppress such warnings, or to generally indicate that a library module, rather than an entire/complete program, is contained in the .f?

Indeed, such behavior might well make sense as a default, in which case offering options to preserve the current behavior (for the warning itself and generally to indicate that an entire/complete program is contained in the .f.