2 Replies Latest reply on Aug 16, 2011 5:03 AM by Martin.Stein

    How to resolve error 0736

    Martin.Stein

      I am evaluating different fortran compilers for an existing project. We have a big interfaces.f90 file, which defines numerous subroutine interfaces for those subroutines not contained in some module. Subroutines not contained in a module (and being in fixed form style) look like:

      subroutine xyz(...)
      use interfaces
      use ... *** code ***
      end subroutine xyz

      When compiling such a subroutine openf95 stops with error 736, and prints:

      openf95-736 openf95: ERROR XYZ, File = xyz.F, Line = 4, Column = 11
      "XYZ" is the name of this program unit, therefore it must not be use associated from module "INTERFACES".

      As far as I understand openf95 complains that (the interface of) subroutine xyz is already declared in interfaces.f90, leadings to this name conflict. Is that correct? And how can I resolve this issue? So far ifort as well as gfortran compile without any complains. Any help is greatly appreciated.

        • How to resolve error 0736
          santosh.zanjurne

          Hello Martin,

          I am still investigating this issue, but a work around could be:

          The interface definition of "xyz" in interfaces module can be renamed to a module local name and this error can be avoided as shown below.

          E.g:

          subroutine xyz(...)
          use interfaces,dummyxyz=>xyz

          use ... *** code ***
          end subroutine xyz

           

          Regards,

          Santosh

            • How to resolve error 0736
              Martin.Stein

              Thanks for your answer, the renaming works indeed. However, applying the workaround to all the files would require to edit quite a bit. I will think on a python script, maybe.

              What I was wondering: Is the openf95 behaviour standard conform and ifort/gfortran just a bit relaxed or is it the other way around? I would guess that ifort/gfortran are correct as our approach seems to be the most obvious one if dealing with legacy code. (Unfortunately, ifort does not check whether the interface in interfaces.f90 conforms with interface of the routine itself, so lots of chances to make erros... I do not know about gfortran).

              Anyway, I also encountered a

              Assertion failure at line 3637 of /local/home/qa/nightly_build_avx/sandbox/open64/osprey/be/lno/simd.cxx:
              ### Compiler Error in file xyz..f90 during Loop Nest Optimizer phase

              when using -O3 optimizer flag with version 4.2.5.2. Flag -O2 does not give this error. I will try to reduce the large source file to reproduce the error with a smaller example.