https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #15)
> Hi Tomas,
>
> > I understand the compiler may not know and typically does not whether the
> > called function accepts "character(len=1)" or "character(len=*)", so it may
> > have to pass the 1. But the situation where I suggest not writing the 1 is
> > more subtle (see my original post -
> > https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html).
>
> I have given this some thought, and I don't think this can be done
> in the general case, unfortunately.
>
> Consider
>
> program main
> call foo("ab")
> end
>
> subroutine foo(c)
> character*1 c
> call bar(c)
> end
>
> subroutine bar(c)
> character*(*) c
> print *,len(c)
> end
>
> This is legal Fortran going back to F77, and it should print 1.
>
> If your proposal was implemented, this would print 2, which would
> be a wrong-code bug :-(
>
> So, what can we do? Previously, the way of interfacing C
> with Fortran was fragile, non-conforming, and worked. Now
> it is fragile, non-conforming, and does not work.
>
> In your (excellent, by the way) debugging work, you have
> identified an option, -fno-optimize-sibling-calls, which
> restores the status quo because things would go back to
> being fragile, nonconforming, and they would work again.
You don't want to do that, that is way big hammer and in some cases, tail call
optimizations are essential for correct program behavior (without the
optimizations for deep recursions you won't fit on stack, while when using them
you will).
If you want some hack to workaround these buggy wrappers (but will their
maintainers then actually fix anything rather than ignoring the problem?),
then I could see tail-calls.c or calls.c punt if it sees DECL_ARTIFICIAL
PARM_DECLs passed on the stack at the end of argument list and it is the
fortran length (it would e.g. help if those arguments would be named with an
initial dot rather than underscore (I believe that used to be the case in the
past)), or we need some way to propagate the info that the argument is hidden
string length through LTO.
