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

[kkylheku at gmail dot com]

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

Kaz Kylheku <kkylheku at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkylheku at gmail dot com

--- Comment #45 from Kaz Kylheku <kkylheku at gmail dot com> ---
Hi everyone.

Pardon my ignorance of C-Fortran bridging matters, but does any of the
following make sense?

The Fortran subroutine has no idea whether the word where the argument is
supposed to be is really the argument, or just some unrelated part of the stack
(because the caller didn't pass the argument).

Can't the Fortran routine check whether that word has the expected value 1?
Then in that case, just pretend it's the argument (whether that is the case, or
whether that 1 is just a spurious value that looks like the right argument). In
this case, just do all the tail calling to sibling routines happily, who will
get the right string length.

If the word does not have value 1, then, uh oh: treat it suspiciously! The
function can then *call itself* with with a *copy* of the arguments, including
the correct length 1. When that call returns, it returns.   The recursively
invoked activation will of course the value of 1, and then act cool.

The downside is that there is a performance penalty with this check and extra
recursive call. When the callers are fixed to pass the argument, the penalty is
reduced, but the check is still being made.