Difference in compile error for Debug and Release configuration

[Antoon]

Compiling F90 code below in Debug Configuration:

real, pointer :: a(:)

i1 = 10
call average(a(i1), ...)


subroutine average(a,b,c)
real :: a(*) <--- obsolete F77 contruct for 'dynamic' arrays

end subroutine

the F90 compiler rightly complains with followingerror message:
error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element.

but in Release Configuration it compiles without error messages.

I checked the difference in properties between configurations, but no result.

Anyone who can explain this different behaviour.

Thanks.

[jimdempseyatthecove]

call average(a(i1), ...)

In the above, a(i1) is a single real variable (a scalar), the i1'th cell of array a.

subroutine average(a,b,c)
real :: a(*)

says a is supposed to be an array.

So what are you trying to average? Scalars or arrays (vectors)?

Jim Dempsey

[jimdempseyatthecove]

BTW

real :: a(*:*)

is the correct way to pass/declare an assumed shape and size array
This won't fix the argument call problem, but will fix the obsolete F77 problem

Jim Dempsey

[Antoon]

Subroutine average is supposed to average the passed array a.

Be aware that this code is from F77 legacy code, where this was working code, apart of course from the F90-specific pointer declaration. In F77 the actual argument a(i1) worked asa so-called start-address for passing the array to the called subroutine.

Okay, long time ago, but we try to minimize the changes.

[jimdempseyatthecove]

If you leave the code as-was
Then compile

without explicit interface
without gen-interfaces warn-interfaces
without IPO with this (these) F77 calling format subroutines/functions.

(compile these files seperately and link as .lib/.obj)

.OR.

fix your code to issue the call with the proper argument

call average(a(i1:),...)

If you want the IPO to include these subroutines and functions then you will have to fix your code.

Jim Dempsey

[mecej4]

This is one of the cases where the Fortran Standard (12.3.1.1, "Explicit interface", clause (2a), (2b)) requires an explicit interface. I gather that you did not provide such an interface.

In such circumstances, the code is faulty; however, the compiler need not detect the fault unless it comes with that capability and is asked to do so (by choosing compiler switches or indirectly, by choosing a "debug configuration").

[TimP]

The only thing which changed in f90 with this syntax is the terminology. There have always been implementations where it was possibly to pass a scalar to an array dummy argument, if the compiler didn't check the syntax, as well as implementations where it failed.
If you're still using a compiler which doesn't check interfaces in Release mode, or if you have disabled checking, it's not surprising there is no message. Until recent versions of ifort, the way to force checking, as other responses mentioned, is by adding an interface block.

[Lorri_M_Intel]

It's the "warn interfaces" feature of the Debug configuration that is provoking this message.

As Steve w has mentioned before, yes, itwas common practice to pass a scalar element of an array to a routine expecting an array, because the storage layout just happened to work.

However, it's not standard.

I would try the suggestion from a previous poster, and use a(i1:) to pass an array slice.

Or, of course, you can turn off the "warninterfaces"property so you don't see the message.

-- Lorri

[jimdempseyatthecove]

When you do correct the call "a(i1:)" and the syntax on the dummy "real :: a(*:*)" I suggest you also perform rigorous testing with array bounds checking enabled. This may catch a bug that may have been hiding inside your code as well as catch a bug introduced by syntax differences between F77 and F90/F2003,...

Example of questionable coding:

real :: array(100)
...
call foo(array(10))
...

subroutine foo(a)
real :: a(*)
...
a = 0.0

What do you expect to happen?
Or should I say: What do you require to happen?

Jim Dempsey

[Antoon]

Thanks for all your help.

In the Debug Configuration the property Fortran| Diagnostics|Generate Interface blocks was set YES, but in the Release Configuration this property was set NO.

That explains why we got all those error in Debug and not in the Release config.

After asking around for this difference between the config's it turned out that they expected a performance penalty in runtime due to checking the interfaces on each call in lengthy calculations.

Does that make sense ??

[Jugoslav_Dujic]

Quoting Antoon

After asking around for this difference between the config's it turned out that they expected a performance penalty in runtime due to checking the interfaces on each call in lengthy calculations.

Does that make sense ??

It does not. The interface checking is made only during compilation, and it presents only a tiny overhead for compile-time anyway. It does not affect the generated code in any way (provided that it's successful, of course).

However, I think the compiler (not the code) is in error here:

[fortran]real, pointer :: a(:)

i1 = 10
call average(a(i1), ...)


subroutine average(a,b,c)
real :: a(*)

end subroutine
[/fortran]

error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element.

Associating a single array element with an assumed-size dummy is maybe old-fashioned, but it is specifically allowed by the Standard, according to sequence association rules. So, Intel folks may wish to revisit the interface checking (if they already haven't).

From Fortran 2003 Draft, emphasis mine:

12.4.1.5 Sequence association

An actual argument represents an element sequence if it is an array expression, an array element
designator, a scalar of type default character, or a scalar of type character with the C character kind [...] If the actual argument is an array element designator, the element sequence
consists of that array element and each element that follows it in array element order.
...
An actual argument that represents an element sequence and corresponds to a dummy argument that is an array is sequence associated with the dummy argument if the dummy argument is an explicit-shape or assumed-size array. The rank and shape of the actual argument need not agree with the rank and shape of the dummy argument, but the number of elements in the dummy argument shall not exceed the number of elements in the element sequence of the actual argument. If the dummy argument is assumed-size, the number of elements in the dummy argument is exactly the number of elements in the element sequence.