Hi!
Fortran subroutines/functions that have CHARACTER arguments have also
hidden arguments at the end of the argument list which hold the string
length. This is something all Fortran compilers I've tried do and is
done in order to support calling unprototyped subroutines/functions
where one can't know if the callee is using character(len=constant)
or character(len=*) argument, where for the latter one has to pass
the extra argument because there is no other way to propagate that info,
while for the former it is kind of redundant but still part of the ABI;
the compiler just uses the constant directly instead of asking about the
real passed string length.
Another thing is that until PR87689 has been fixed, the Fortran FE has been
broken, used vararg-ish prototypes in most cases and that prevented (all?)
tail call optimizations in the Fortran code.
Apparently it is a common case that buggy C/C++ wrappers around the Fortran
functions just ignore the ABI and don't pass the hidden string length
arguments at all, which seemed to work fine in gfortran until recently
(because the arguments weren't used). When we started making tail calls
from such functions, this has of course changed, because when making a tail
call we overwrite the caller's argument slots with the arguments we want to
pass to the callee. Not really sure why it seemed to work with other
compilers; trying https://fortran.godbolt.org/z/ckMt1t
subroutine foo (a, b, c, d, e, f, g, h)
integer :: b, c, d, e, f, g, h
character(len=1) :: a
call bar (a, b, c, d, e, f, g, h)
end subroutine foo
both older/new gfortran and ifort 19.0.0 emit a tail call which overwrites
the hidden string length argument with 1, but when trying the
https://fortran.godbolt.org/z/xpsH8e LAPACK routine, ifort for some reason
doesn't tail call it.
I'm not really happy to provide workarounds for undefined behavior,
especially because that will mean it might take longer if ever if those
buggy programs are fixed. On the other side, the PR87689 bug fix has been
backported to all release branches and so now not only trunk, but also 9.1,
8.3.1 and 7.4.1 are affected. Instead of trying to disable all tail calls,
this patch disables tail calls from functions/subroutines that have those
hidden string length arguments and don't use character(len=*) (in that case
the function wouldn't seem to work previously either, because the argument
is really used), where those hidden string length arguments are passed
on the stack and where the tail callee also would want to pass arguments
on the stack (if we spent even more time on this, we could narrow it down
further and check if the tail call would actually store anything overlapping
the hidden string length arguments on the stack).
This workaround probably needs guarding with some Fortran FE specific
option, so that it can be disabled, will defer that to the Fortran
maintainers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
release branches (not sure about LTO on the release branches, does one need
to bump anything when changing the LTO format by streaming another bit)?
2019-05-16 Jakub Jelinek <ja...@redhat.com>
PR fortran/90329
* tree-core.h (struct tree_decl_common): Document
decl_nonshareable_flag for PARM_DECLs.
* tree.h (DECL_HIDDEN_STRING_LENGTH): Define.
* calls.c (expand_call): Don't try tail call if caller
has any DECL_HIDDEN_STRING_LENGTH PARM_DECLs that are or might be
passed on the stack and callee needs to pass any arguments on the
stack.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Use
else if instead of series of mutually exclusive ifs. Handle
DECL_HIDDEN_STRING_LENGTH for PARM_DECLs.
* tree-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.
* trans-decl.c (create_function_arglist): Set
DECL_HIDDEN_STRING_LENGTH on hidden string length PARM_DECLs if
len is constant.
