https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #15 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- 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. Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9, I would suggest that we make -fno-optimize-sibling-calls the default on these branches. Maintaining binary compatibility (even if it is bug compatibility) with existing packages is something we should strive for, especially with such important software packages as BLAS and LAPACK. These packages are one important reason why people still use Fortran, and I would hate to push them towards flang with this. For current trunk, I would recommend keeping the current hehavior and contact the LAPACK maintainers to a) give them a heads-up for this problem, and b) a year to work out the problem. Would this be something that people could agree on?