Migration from PGI to Intel Fortran, What is this error ?

[Rambod_M_]

So I am trying to move my working codes from PGI Fortran to Intel, I am using student free version of compiler for Intel and Microsoft Visual Studio 2013 Community version.

My perfectly running code in PGI, gets following error (attached image) when it comes to compiling with Intel Compiler. That is except that some other errors that I could solve (difference how they interpret INTENT(IN) ).

So why I am getting this error and how can I solve it?

Should I expect something unusual going on somewhere and redo checking my results ? i.e. when I choose INTEN(IN) in a subroutine with PGI, I could change the value of the parameter, but this changed value did not effect the parameter "out side the routine" (where it was initially called). So I had it defined as a " Parameter" in the main body of program, passed it inside the routine, changed it value, but the changed value did not pass outside!  but it seems I cannot do such with Intel

[mecej4 · Accepted solution]

Your code probably has large local arrays that are allocated on the stack at function/subroutine entry. You can specify a higher stack allocation with the linker option /stack:, or change some of the large local array variables to static allocation (in a common block or in a module or with the SAVE attribute in the declaration), or change the arrays to dynamically allocated arrays.

[FortranFan]

Try compiling your code in Intel Fortran using -stand compiler option and see what shows up: https://software.intel.com/en-us/node/579528

[andrew_4619]

if the compiler sees an attempt to modify an intent(in) then it should show an error, that is the correct behaviour. You are wanting maybe  to pass by value so the variable remains unchanged external to the subroutine. You can have the "value" attribute on the declaration or alternatively copy the variable to some other name in the subroutine and work on the copy....

[Rambod_M_]

mecej4 wrote:

Your code probably has large local arrays that are allocated on the stack at function/subroutine entry. You can specify a higher stack allocation with the linker option /stack:, or change some of the large local array variables to static allocation (in a common block or in a module or with the SAVE attribute in the declaration), or change the arrays to dynamically allocated arrays.

So how can I change linker option in VS?

[Rambod_M_]

app4619 wrote:

if the compiler sees an attempt to modify an intent(in) then it should show an error, that is the correct behaviour. You are wanting maybe  to pass by value so the variable remains unchanged external to the subroutine. You can have the "value" attribute on the declaration or alternatively copy the variable to some other name in the subroutine and work on the copy....

So why isn't it the case in PGI? and do you know what else might have happened that I should be careful of? I mean the differences of PGI & Intel!

[Kevin_D_Intel]

App4619 is correct. Attempting to modify INTENT(IN) is an error as per the Fortran Standard (Section 5.3.10 paragraph 2) saying:

"The INTENT (IN) attribute for a nonpointer dummy argument specifies that it shall neither be defined nor become undefined during the invocation and execution of the procedure."

I can’t speak to why PGI might default to permitting this (if it does) but the Intel compiler does not. We issue: error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.

If desired, as shown in the small example below, one can do what you described with PARAMETERs with the Intel compiler but only with INTENT(INOUT) and /assume:noprotect_constants   -OR-  under the IDE  Data > Constant Actual Arguments Can Be Changed (See more on /assume here, https://software.intel.com/en-us/node/579519). Maybe that can help alleviate major changes at this stage of the port if that's something significant you are facing.

I am not aware of a reference that could help with differences between the two compilers. Sorry I can’t be of help with that.

program alpha
  integer, parameter :: j=1

  call beta(j)
  write (*,"(2x,A,I1)"),"alpha after: ",j
end program alpha

subroutine beta(i)
  integer,intent(inout) :: i

  write (*,"(2x,A,I1)"),"beta before: ",i
  i=5
  write (*,"(2x,A,I1)"),"beta  after: ",i
end subroutine beta

$ ifort /assume:noprotect_constants alpha.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.110 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.23026.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:alpha.exe
-subsystem:console
alpha.obj

$ .\alpha.exe
  beta before: 1
  beta  after: 5
  alpha after: 1

[FortranFan]

Kevin Davis (Intel) wrote:

.. I can’t speak to why PGI might default to permitting this (if it does) but the Intel compiler does not. We issue: error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.

If desired, as shown in the small example below, one can do what you described with PARAMETERs with the Intel compiler but only with INTENT(INOUT) and /assume:noprotect_constants   -OR-  under the IDE  Data > Constant Actual Arguments Can Be Changed (See more on /assume here, https://software.intel.com/en-us/node/579519). Maybe that can help alleviate major changes at this stage of the port if that's something significant you are facing. ..

Kevin,

OP mentions a runtime error (severe (170) .. stack overflow), not a compiler error.  So it's unclear what the exact situation is.  If the code is indeed analogous to what you show, I wonder how error #6780 was bypassed - it was suppressed maybe?

Anyways, if the OP wants to similar to what you show, then the better option I think is to apply the VALUE attribute from the standard and supported by Intel Fortran: this way, no compiler-specific actions are needed and the code would read clearer.

program p

   integer, parameter :: j=1

   call beta(j)

   write (*,"(2x,A,I1)") "alpha after: ",j

   stop

contains

   subroutine beta(i)
      integer, value :: i

      write (*,"(2x,A,I1)") "beta before: ",i
      i=5
      write (*,"(2x,A,I1)") "beta  after: ",i
   end subroutine beta

end program p

  beta before: 1
  beta  after: 5
  alpha after: 1
Press any key to continue . . .

[Kevin_D_Intel]

Hi FortranFan,

Yes, agreed. It was unclear whether the OP  was experiencing anything related to the PARAMETER and without a code snippet and more details I was speculating.

I thought perhaps the OP’s code already contained INTEN(IN) and the interest was in keeping some form of INTENT. I did not suggest VALUE since my experience with various alternatives was not successful, but I never tried yours.

The compiler rejects VALUE, INTENT(INOUT):

$ ifort /nologo alpha.f90

alpha.f90(9): error #7287: A dummy argument has both the VALUE attribute and an explicit INTENT(OUT) F90 attribute.   
  integer,value,intent(inout) :: i
---------------------------------^
alpha.f90(8): error #8039: The INTENT(OUT) or INTENT(INOUT) attribute is not allowed for arguments received by value.   
subroutine beta(i)
----------------^
compilation aborted for alpha.f90 (code 1) 

It also rejects  VALUE, INTENT(IN):

$ ifort /nologo alpha.f90

alpha.f90(12): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.   
  i=5
--^
compilation aborted for alpha.f90 (code 1)

I confirmed your example and am perplexed. The Standard and Fortran User’s Guide both say that if no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the associated actual argument. With the actual argument being a PARAMETER, I thought the limitation of those not being re-definable would apply.

With your test case, the error below at least confirms the limitation in the context of the actual argument where such leads to an error when throwing in an assignment to J. I do not understand how the compiler treats the actual argument in the case you showed since that limitation does not seem to carry into the content of dummy argument where as you showed VALUE works.

$ ifort /nologo alpha.f90

alpha.f90(4): error #6414: This PARAMETER constant name is invalid in this context.   
  j=2
--^
compilation aborted for alpha.f90 (code 1)

[mecej4]

Kevin Davis wrote:
The Standard and Fortran User’s Guide both say that if no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the associated actual argument. With the actual argument being a PARAMETER, I thought the limitation of those not being re-definable would apply.

As Dr. Fortran might say, that limitation applies to the programmer/input source code, not the compiler.

Another way of looking at the situation is to consider this as a quality of implementation issue. There are a large number of programming errors that the standard does not require the compiler to diagnose. Users, however, would like to be able to catch such errors, perhaps by specifying extra "check" flags.

In a Fortran 77 context, where you could only have external (as opposed to CONTAINed) subprograms, the explanation is very simple. The subroutine may be called sometimes with definable arguments, and at other times with expressions or constants, even within a single run of the program. Therefore, all checking of arguments as to writeability has to be done in the caller(s).

When doing a (separate) compilation of a subprogram, the compiler cannot know if the actual argument will be a constant or a variable. Some Fortran 77 compilers took care of this by using an anonymous variable as the actual argument, with the input value (constant or expression) copied into the anonymous variable. Any changes to the dummy argument in the subroutine would change only the anonymous variable, leaving the original entity (constant or expression) untouched. Other compilers placed constants into write-protected segments, in which case passing a constant as an actual argument and the subprogram's attempting to change it would cause an access violation.

Suggestion to O.P.: Please, do not hunt for compiler options to make two compilers deal with non-conforming code in the same way. Fix the code to make it conform to the standard.

[Kevin_D_Intel]

Hopefully it was clear my intentions were only in offering temporary relief as part of the porting process. Certainly one must circle-back and address issues found in the most appropriate manner. I agree with your final suggestion too.

[FortranFan]

Kevin Davis (Intel) wrote:

.. I confirmed your example and am perplexed. The Standard and Fortran User’s Guide both say that if no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the associated actual argument. With the actual argument being a PARAMETER, I thought the limitation of those not being re-definable would apply. ..

Thanks, Kevin.  I think the intent (no pun intended!!) in the Fortran standard is VALUE attribute can either be used with no INTENT attribute or with INTENT(IN) (e.g., with TYPE(C_PTR)):

As you indicate, the OP is unclear what the needs are and provides no code snippets.  It may be that INTENT(IN) for dummy and PARAMETER for actual were used as a way to get around the concept of not wanting to get the actual argument to get modified in the procedure (yet another conjecture).  If that is the case, the use of VALUE would be an option for OP to consider.

Regards,

[Kevin_D_Intel]

Thanks for clarifying FortranFan.

[JVanB]

Is INTENT(IN) perhaps a red herring here? After all, if the compiler passed by VALUE when only INTENT(IN) were specified, programs like this would fail:

module M
   implicit none
   contains
      subroutine S(x,n,p)
         integer, intent(in) :: n
         real, intent(in), target :: x(2)
         real, pointer :: p
         p => x(2)
      end subroutine S
end module M

program P
   use M
   implicit none
   real, target :: x(10)
   real, pointer :: p1, p2
   call S(x,size(x),p1)
   p2 => x(2)
   write(*,'(3a)') 'p1 and p2 ',trim(merge('ARE    ', &
      'are NOT',associated(p1,p2))),' associated.'
end program P