forrtl: warning (402): an array temporary was created why?

[burovski]

Hello all,
I'm creating a simple 'vector' type with overloaded basic operations like adding, assignment and so on. I'm hiding the implementation into a module. As a bare minimum I have to provide a facility to assign a 'usual' array to a 'vector'. When compiled with Intel Fortran 10.1 compiler under Ubuntu, I am receiving a warning that an array temporary is created. Googling tells me that this warning is usually associated with mixing fortran 77 arrays (contiguous in memory) and fortran 90 arrays (not necessarily contiguous).

What I'm confused about is that in the code below I don't seem to be ever using fortran 77 style arrays. It seems that I'm missing something kindergarten-ish, but I can't figure what is the issue. Can anybody clarify it?

Here's the offending code:

!-----------------------------
module blah
implicit none

integer,parameter :: d=3 ! dimension

public assignment(=), momentum,d,dump

private

! basic type itself
type momentum
private
integer, dimension(d) :: elem
end type momentum

interface assignment(=)
module procedure arr ! assign arr to vector
end interface

contains

! assign array to vector --- the offending procedure
subroutine arr(ve,ar)
implicit none
type(momentum), intent(out) :: ve
integer, intent(in) :: ar(d)
ve%elem=ar
end subroutine arr

end module blah

!+++++++++++++++++++++++++++++++++++
program trrry
use blah
implicit none
type(momentum) :: ve
integer :: a(d)

a=1;
ve=a; ! this call generates the warning

end program trrry

[Steven_L_Intel1]

I think the issue is that the semantics of defined assignment are that the right side is completely evaluated before any stores to the left side are done. The compiler is not recognizing that there is no overlap and, conservatively, creates a temporary copy of the right side before calling the assignment routine. To the part of the compiler that processes this, it looks like a normal call to a subroutine and hence you get the warning (which is optional and comes from -check arg_temp_created).

[burovski]

Dear Mr. Lionel,

Thank you very much for the answer!
Is there a way to avoid creating such temporary?
It's a minor issue of course; my main reasons for wanting it is that it's a routine which is called repeatedly in my code --- hence I'd really prefer getting maximum performance for it.

Thanks again,
Zhenya

[Steven_L_Intel1]

Not that I can think of. To be honest, I'm a bit surprised that the temp is there because we have an open issue where such assignments where overlap is possible gives bad results. Perhaps the temp was the initial fix for this. I'll have to ask about this. but there is no control that I am aware of.

[burovski]

OK, no way it is then. Thanks a lot!

Quoting - Steve Lionel (Intel)

Not that I can think of. To be honest, I'm a bit surprised that the temp is there because we have an open issue where such assignments where overlap is possible gives bad results. Perhaps the temp was the initial fix for this. I'll have to ask about this. but there is no control that I am aware of.

[Steven_L_Intel1]

I confirmed this was the case. The standard says that your routine is called "as if" the right side were enclosed in parentheses, making it an expression. In such cases, we pass a copy. You can't disable this.

[joseph-krahn]

Quoting - Steve Lionel (Intel)

I confirmed this was the case. The standard says that your routine is called "as if" the right side were enclosed in parentheses, making it an expression. In such cases, we pass a copy. You can't disable this.

I think the purpose of this warning is that such temps can create overhead, but the overhead for a size 3 vector is not very significant. It would be useful to print the size of the temp so that messages could be sorted or filtered, and maybe have a built-in size threshold for printing.

Actually, this example produces a temporary known at compile time. Why not print a warning at compile time? Even when tempraries are conditional (i.e. due to strided array refs), the compiler could print a conditional-temp warning. Compile-time messages would make it easier to avoid temp-generating constructs.