[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

jb at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon May 6 11:46:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329

--- Comment #12 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Tomas Kalibera from comment #11)
> At least in the case I debugged, I think gfortran could do better by not
> writing the 1 as string length to the place on the stack where the compiler
> knows there is already 1 as string length.

The problem is not that the compiler gets the wrong string length, in this case
when the procedure argument is defined to have a length of 1, the compiler
never needs to access the hidden string length argument [1].

The problem is that both the caller and the callee need to agree on the number
(and type) of arguments. And because in Fortran implicit interfaces
("F77"-style interfaces, without modules, interface blocks or any other
newfangled "modern Fortran" stuff) the only information about the interface of
a procedure that the caller knows is the name of the procedure. So for an
example compiling the code

call foo("abc")

the compiler has no knowledge of the procedure beyond the name "foo". From this
code the compiler can then deduce that it must be a subroutine, and that it
takes one argument of type character.  But the compiler cannot verify this, it
must assume the programmer knows what he's doing. Now, the problem is that the
definition of the procedure can be

subroutine foo(a)
    character(len=1) :: a
    ....
end subroutine foo

or

subroutine foo(a)
    character(len=3) :: a ! Or len=2
    ....
end subroutine foo

or

subroutine foo(a)
    character(len=*) :: a
    ....
end subroutine foo


In the first two the hidden string length argument is not needed, but because
the procedure ABI must match for all the possibilities, and for the third case
the hidden length IS needed, the hidden string length argument is always
needed, although it's unused when the length is fixed.


[1] It would be possible to have some optional debugging option which inserts
code to verify that the actual argument length >= the dummy argument length.
But that's not really related to this issue.


More information about the Gcc-bugs mailing list