Software Archive
Read-only legacy content
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
17060 Discussions

Is this part of F90 standard?

Intel_C_Intel
Employee
774 Views
Hi all,

Here is the scenario:


PROGRAM test 
REAL :: x(10) 
 
CALL sub(INT(x)) 
END PROGRAM 
 
SUBROUTINE sub(y) 
INTEGER :: x(:) 
END SUBROUTINE 

Is there anything in the F90 standard that says that I shouldn't be able to pass INT(x) as an argument to sub because it is an I*4 expression being passed to a dummy arg which is an I*4 array?

I am running a fortran lint program that is complaining about just such a situation, but I see nothing in the standard that says this is not allowable since the return value of INT(x) should, in fact, be an I*4 array.

Thanks in advance,
Chris
0 Kudos
4 Replies
Steven_L_Intel1
Employee
774 Views
Did you perhaps mean y(:) in the subroutine? As written, y is real and conflicts with the integer type of INT(x).

Now if you did mean y(:), then you have another problem - y is a deferred-shape array for which you cannot pass a scalar. Also, a deferred-shape array requires an explcit interface to be visible to the caller.

Now, let's see what happens if you had declared Y as Y(*) instead (assumed-size). The standard prohibits this, saying, "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."

So, this code is non-standard no matter how you slice it.

Steve
0 Kudos
Intel_C_Intel
Employee
774 Views
Hi Steve,

Yes, I did mean y(*) in the subroutine. Sorry for the confusion.

I guess my point is that since x is declared as an array in the program scope, and INT now being a generic interface in F90, then shouldn't INT(x) actually return an array of integers? If so, then shouldn't the call to sub be passing an array of integers to the subroutine?

And if that is the case, then I see no reason why the compiler should treat it any differently than if I were to pass any other fixed dimension integer array.

As it stands right now, CVF will successfully compile this situation, as amended above, with F90 standards checking turned on. It's only flint that seems to complain.

Thanks,
Chris
0 Kudos
Steven_L_Intel1
Employee
774 Views
Darn - missed that X was an array and therefore INT(X) is an array. With Y(*) as the argument declaration, this looks ok to me.

Steve
0 Kudos
Jugoslav_Dujic
Valued Contributor II
774 Views
Your code is allowed, but what matters is what you do with x in sub. Try adding INTENT(IN) to declaration of x in sub. If CVF accepts the code, flint is wrong. However, if it doesn't, that means that you tried to change value of x in the subroutine, but actual argument is not a variable, but an expression. I'm not sure if this is allowed by the standard (but it's not required for compiler to recognize it without an explicit interface -- that's why tools like flint exist after all).

In the actual case, though, I believe (though I'm not positive) that even that should do no harm, since temporary INT(x) is created on the stack and removed after CALL so whatever changes on formal argument subroutine had done would just go down the drain without overwriting anything relevant.

Jugoslav
0 Kudos
Reply