https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kargl at gcc dot gnu.org --- Comment #16 from kargl 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. > > 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? Does -fno-optimizing-sibling-calls effect performance? A 1% (or less) degradation may be considered negligible, and an acceptible compromise. 10% would be unacceptable. Guess I'll need to dust off my old copy of the Polyhedron Benchmarks and run a few tests.