Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

How to solve error #6633 in fixed format

Jian_G_
Beginner
1,051 Views

Let me separate the problem to 2 parts.

Part I:

Such error occurs, when compiling the following code.

--------free format-----------

program ex0815
    implicit none
    real::a=1.0
    call showinteger(a)
    call showreal(a)
    stop
    end
    
    subroutine showinteger(num)
    implicit none
    integer::num
    write(*,*)num
    end
    
    subroutine showreal(num)
    implicit none
    real::num
    write(*,*)num
    end

---------end-----------

error #6633: The type of the actual argument differs from the type of the dummy argument.  

The error can be removed by adding the directive:"!DEC$ ATTRIBUTES NO_ARG_CHECK :: dummy_arg_name"

Part II:

If rewrite the code in fixed format.

------------fixed format---------------

      program ex0815
      implicit none
      real::a=1.0
      call showinteger(a) !DEC$ ATTRIBUTES NO_ARG_CHECK :: dummy_arg_name
      call showreal(a)
      stop
      end
    
      subroutine showinteger(num)
      implicit none
      integer::num
      write(*,*)num
      end
    
      subroutine showreal(num)
      implicit none
      real::num
      write(*,*)num
      end

-------------end--------------

The error #6633 can not be removed by the same way.

So how to deal with error #6633 in fixed code format?

PS I'm trying to recompile a program wrote in fixed format and originally compiled with compaq fortran(standard F77). Hundreds of error #6633 occurs, when compiling with intel visual fortran. It is quite NOT convenient to rewrite the code in free format. I would appreciate it very much if there is an simple way to solve the problem.

THANKS 

0 Kudos
7 Replies
Arjen_Markus
Honored Contributor I
1,051 Views

I am not sure I understand what you are after: there is a clear error in your program that you may be able to suppress by requiring the compiler to ignore it, but that does not make the error go away. Instead of trying to suppress the error message you should spend the effort to correct them.

There is no need to convert everything to free form - both fixed form and free form are supported by the compiler and indeed the standard. Haphazardly passing real arguments to routine that use them as integers is not a reliable way of programming, however.

0 Kudos
Lorri_M_Intel
Employee
1,051 Views

In the second case, you probably have exceeded the 72-column default.

 

0 Kudos
andrew_4619
Honored Contributor II
1,051 Views

The following prefix forms can be used in place of !DIR$: cDIR$, cDEC$, or !MS$, where c is one of the following: C (or c), !, or *.

The following prefix forms can be used in place of !$OMP: c$OMP, where c is one of the following: C (or c), !, or *.

The following are source form rules for directive prefixes:

  • In fixed and tab source forms, prefixes begin with !, C (or c), or *.

    The prefix must appear in columns 1 through 5; column 6 must be a blank or a tab (except for prefix !MS$). From column 7 on, blanks are insignificant, so the directive can be positioned anywhere on the line after column 6.

  • In free source form, prefixes begin with !.

    The prefix can appear in any column, but it cannot be preceded by any nonblank, nontab characters on the same line.

  • In all source forms, directives spelled with two keywords can be separated by an optional space; for example, "LOOP COUNT" and "LOOPCOUNT" are both valid spellings for the same directive. However, when a directive name is preceded by the prefix "NO", this is not considered to be two keywords. For example, "NO DECLARE" is not a valid spelling; the only valid spelling for this directive is "NODECLARE".

A compiler directive ends in column 72 (or column 132, if compiler option extend-source is specified).

0 Kudos
cryptogram
New Contributor I
1,051 Views

Certainlly not a best practice, but for old code I understand why someone might do something like this....

Back in the days when Fortran didn't include any way to do dynamic allocation of arrays, sometimes people would code this way to

implement it themselves.  At the top of the code the programmer would dimension the largest array they could get away with. 

Then, after reading input data that determined how much space was required for all of the working arrays, you'd see subroutine calls like this:

 

call  sub1(bigarray(1), n1, biggarray(n1+1),n2, bigarray(n1+n2+1), n3))

and then on the other side of the call

 

subroutine sub1(rarray,,n1,iarray,n2,r2array,n3)

dimension  rarray(n1), iarray(n2), r2array(n3)

 

So it's a case where you rely on "call by reference" and argument association as a workaround for not having dynamic allocation

available.  

 

 

 

0 Kudos
Guthrie_M_
Beginner
1,051 Views

Excuse me folks, but the fixed format example code at the top of this thread is exactly what I'm am interested in getting to compile and would like an explicit fix. Here is the code (changed to not exceed 72 columns) repeated:

      program test
      implicit none
      real::a=1.0
      call showinteger(a)!DEC$ ATTRIBUTES NO_ARG_CHECK::dummy_arg_name
      call showreal(a)
      stop
      end
    
      subroutine showinteger(num)
      implicit none
      integer::num
      write(*,*)num
      end
    
      subroutine showreal(num)
      implicit none
      real::num
      write(*,*)num
      end

when I compile using C:\Intel\bin\ia32\ifort.exe /wrap-margin- -traceback /gen-interfaces /warn:interfaces /fpe:0 /check test.for

I get this error message:

test.for(4): error #6633: The type of the actual argument differs from the type of the dummy argument.  
      call showinteger(a)!DEC$ ATTRIBUTES NO_ARG_CHECK::dummy_arg_name
-----------------------^
compilation aborted for test.for (code 1)

It will compile if I remove /warn:interfaces, but I'd like to have that check being done for the rest of the code.

Thanks for any help,

G

0 Kudos
Steven_L_Intel1
Employee
1,051 Views

That !DEC$ text needs to be on its own line. It is not recognized at the end of a line.

0 Kudos
John_Campbell
New Contributor II
1,051 Views

An alternative approach could be:

program ex0815
    implicit none
    real::a=1.0
    integer::i
    i = transfer (a,i)
    call showinteger(i)
    call showreal(a)
    stop
    end

 

0 Kudos
Reply