Q re subroutine interface rules - BUG(?)

[WSinc]

Hello -

My understanding is that when you compute an expression, say with an integer, the
result is the same BYTE size. Isn't that the standard?
However, I came across this situation:

Program test
integer*2 level/4/
call sub1(level+1)
end

subroutine sub1(level)
integer*2 level
print *,"level=",level
end

This generates a warning (#6075) mesage about unequal sizes, as if level+1 isNOT the same size.
To make the warning messge disappear, I have to say:

call sub1(int2(level+1))

Perhaps I don't undersatnd the rule regarding this situation.
But shouldn't the compiler KNOW what size is expected in the called subroutine arguments?

[Steven_L_Intel1]

A couple of things here.

In the expression level1+1, the 1 is "default integer kind", or integer(4). The language rules are that when you add these two together you get integer(4), so that doesn't match integer(2).

Second, strictly speaking the compiler doesn't know what is expected, since sub1 is an "external procedure" with an implicit interface. It knows nothing about the routine. Intel Fortran has a feature Generated Interface Checking where it can see how sub1 is declared and thus it can give you the error. Without that it would be silent.

You could also fix this by writing level1+1_2 , which makes the constantt integer(2).

[WSinc]

Still some confusion here:

If I put a LITERAL in the calling sewquence, how does the compiler know what TYPE to make it?

For example CALL SUB1(5)

If I said, for example, 5 in the argument list, doesn't it know to make it 5_2?
I assume it knows that from having already compiled SUB1 before.

So doesn't it keep track of called dummy arguments in other routines?
At least in the past, I never had to be explicit about its size, but maybe its a good practice to do so.

When I put an EXPLICIT literal of the WRONG size, no messagesare generated.
Why is that? Why no warning?

Ex: CALL SUB1(5_4)

Actually, it HAS to know something about the dummy arguments, otherwise
why would it generate warning messages about the incompatibiility between
them?

If they were really independent, the mismatch would only be detected when they are linked together.

[Steven_L_Intel1]

How does it know what type to make the literal? Simple - the standard defines it. In your example, the literal 5 is an integer of default integer kind. What that default is is implementation-dependent (and can also be modified with compiler options), but for Intel Fortran it is INTEGER(4). Similarly, the litersl 3.14 is "default real kind" or REAL(4). Even if you wrote 3.1415926535897, that is REAL(4) and all those extra digits are thrown away. So no, the compiler would not necessarily know to make that 5_2. However, the Intel compiler has an extension where if you pass an integer literal to an argument that it sees takes a smaller integer kind, it doesn't give an error or warning, because we know that is harmless.

As I explained earlier, when you have separate subroutines there is only "implicit interface", where the compiler doesn't know anything about the called routine except its name. (I am assuming here that no INTERFACE block has been provided.) Intel Fortran has an enhancement, though, where it collects information about external procedures in your program and uses that for error checking, hence the warning. If you turn off that feature, you will get no warning for this type of mismatch.

As for linking together, there is no information available that would detect a mismatch of argument type.

[dboggs]

I'm having a peculiar problem that MAY be related to this, in that the compiler sometimes lets something through to a subroutine that SHOULD give an error, or at least a warning, but not always.

In my case, I attempt to pass an assumed-shape array to a subroutine without an explicit interface. Being a greenhorn in such matters and often trying to learn by trial-and-error reverse engineering, I observed that the program ran fine while I was developing it.When I made a release version and gave it to someone else, then it crashed! Only after a couple of hours of investigating the crash did I track it down to the lack of explicit interface.

In other words, the compiler's checking and warnings seems to be more gracious in debug mode than in release mode. Could this observation also apply to Bill's issue?

This behavior puts a real crimp in the trial-and-error technique of trying to learn how to do things right!

[Steven_L_Intel1]

No, there is no correlation. Furthermore, an explicit interface is not required when passing an assumed-shape array. An explicit interface is required if the called routine has a dummy argument that is assumed-shape. The generated interface checking will usually catch this error.

[WSinc]

I don't understand "harmless."

if for example I have

CALL SUB1(129)

and SUB1 has that argument typed as integer*1, it will only get the LAST 8 bits of the number, which would come out as = 1.

If on the other hand, the calling routine has it typed smaller, then the called routine will pick up GARBAGE
for the leading eight bits. For example CALL SUB1 (27_1)

In both cases there is a problem, right ?

[Steven_L_Intel1]

Yes, a case such as that is not harmless. It is in the usual case. If you compile with standards checking and generated interfaces you'll get something like this:

t.f90(1): warning #7320: Standard F2003 requires that the type AND type parameters of the actual argument be the same as the type AND type parameters of the dummy argument. [129]
call sub(129)
---------^

[WSinc]

I can see where an explicit interface would be desirable.

Somehow the compiler must look for that when it sets up the called arguments, right?

Is there a default where the behavior of the called subroutine can DEPEND upon the type of calliing arguments?

For example, can I have a subroutine that allows EITHER integer, real or logical inputs?

Perhpas it would be an optional argument?

[mecej4]

> can I have a subroutine that allows EITHER integer, real or logical inputs?

Yes, but not in the way that you probably meant.

You can create a module containing a number of routines that have identical argument lists except for argument types, and "overload" them with a generic name, and call these routines using the generic name. The compiler will arrange to have the appropriate procedure called based on the types of the actual arguments. The call has to be resolvable at compile time.

Several examples, in particular sort routines for sorting arrays of different types, have been published in comp.lang.fortran and other places.

[Steven_L_Intel1]

A couple of my early VF Newsletter posts will be of interest to you, Bill.

Doctor Fortran and the Virtues of Omission

Doctor Fortran Gets Explicit!

[Steven_L_Intel1]

Sigh - I forgot to point you at my newest entry on this subject:

Doctor Fortran Gets Explicit, Again!

[dboggs]

In my program, subroutine SPLOT passes array B to SUBROUTINE AtoB(A, B) which has REAL :: B(:,:). I get a compiler warning#7978 "Required interface for passing assumed shape array is missing from original source." I ignore the warning. The debug version runs OK but the release version bombs.

I will take this up in another thread, lest this one get too confusing with apparently unrelated content.