CodethinkLabs/ofc

EXTERNAL Declarations Omitted From .inc Files

jcburley opened this issue · 5 comments

jcburley commented

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).

ben-brewer-codethink commented

This was intentional behavior under the belief that F90 doesn't support the EXTERNAL keyword, however looking at it, it seems obvious that by omitting it we're changing the behavior of the code. I'll add a re-print function for this.

ben-brewer-codethink commented

This should now be fixed.

jcburley commented

I'm not sure the fix is quite correct. First, the compiler now warns about an unused variable -- which doesn't make sense when processing a .inc file; second, the compiler adds a REAL declaration for the name, which seems wrong if it names a subroutine:

$ ofc --sema-tree external.inc > external-new.inc
Warning:external.inc:1,15:
   Variable 'FOO' declared but not used
      EXTERNAL FOO
               ^
$ cat external-new.inc
        REAL :: FOO
        EXTERNAL FOO

I think all it should do is silently output EXTERNAL FOO.

Otherwise, while gfortran accepts the original, it complains about the processed version:

$ cat use-foo-new.f
        include 'external-new.inc'
        call foo
        end
$ gfortran -o use-foo use-foo-new.f
external-new.inc:1.19:
    Included at use-foo-new.f:1:

        REAL :: FOO                                                     
                   1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'foo' at (1)
external-new.inc:1.19:
    Included at use-foo-new.f:1:

        REAL :: FOO                                                     
                   1
use-foo-new.f:2.72:

      call foo                                                          
                                                                        2
Error: 'foo' at (1) has a type, which is not consistent with the CALL at (2)
$
jcburley commented

(I'm not sure whether to make this a new issue, or change the status of this issue, or what.)