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

[kargl at gcc dot gnu.org]

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.