Integer length issues between program and subroutine

[tashker__michael]

This has changed between CF6.x and Intel 8.x:

If you pass an Integer*2 variable to a subroutine in which it's declared as integer*4, the correct value doesn't carry to in the subroutine. For example:

integer*2 i2var
i2var=30
print *,"before call", i2var
call somesub(i2var)
print *, "after call",i2var
...

subroutine somesub(subvar)
integer*4 subvar
print *,"before assignment",subvar
subvar=40
end

The 'print before' and 'print after' values will be correct, but the 'before assignment' value will be, say, 1179678.

Anyone know ofa compile or link-time switch to get back the old CF behavior? Else I gotta go through a whole lotta code...

[Steven_L_Intel1]

You were relying on a bug which we fixed. Sorry. There's no switch to bring back the old, buggy behavior.

[Peter_Priestley]

In my experience CVF does it too for Release builds in 6.6B.

This lack of type safety with Integer arguments is a real pain (I speak from experience, trying to maintain Fortran code written by others.)

In my opinion, it would be better if:-

• There was an error at link time to warn of the mismatch, or
• Mismatched numeric types were implicitly 'cast' to the correct type.

Fortran could learn a bit from C as far as type safety goes.

PP.

[Steven_L_Intel1]

Coming to an Intel compiler near you sometime later this year:

t2.f90(4) : Warning: The data type of the actual argument does not match the definition. [I2VAR]
call somesub(i2var)
-------------^

You will have to ask for this level of consistency checking - it will not be the default. It will also work across files in many cases.

I'll also repeat my mantra of "always use explicit interfaces".

[tashker__michael]

Sigh. I'll have to grep like crazy now to find those problems (which BTW are the same for Real*4 and *8). Serves me right. With respect to interfaces, I must say that C-style interfaces are one line, Fortran-style are more of a pain (and must be included in every routine, not just once per input file).

I hope someday to learn what Steve means when he says "It will also work across files in many cases". I guess that means tinkering with the linker, unless all routines must be placed in a single file.

[Steven_L_Intel1]

No linker involved. But it will work best when you compile the source with the routine before the source that calls it. Basically, the compiler has the ability to generate and automatically compile, for each global routine it sees, a module with an interface for that routine that specifies argument names,data types and array rank (if any). The compiler can also automatically look for these generated modules when it sees a call to a routine for which there is no explicit interface, and see if they match. It's not quite as good as an interface you might write - no INTENT, for example - but it will catch the majority of errors.

It's something we were playing with back in the CVF days but never got it finished. I imagine that the initial release will show some rough spots that you folks will let us know about.

You can make a Fortran interface all on one line if you like - with semicolons. The only real advantage C has is that its type names tend to be shorter. But Fortran purists would tell you to put the routines themselves in a module, so you don't have to write separate interfaces.