https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 7 May 2019, jb at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 > > --- Comment #18 from Janne Blomqvist <jb at gcc dot gnu.org> --- > (In reply to Thomas Koenig from comment #15) > > 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. > > +1. Especially considering Steve's benchmark suggesting there's practically no > difference, although there may of course be other code where sibling call > optimization makes a difference. > > > 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. > > Yes. Closer to GCC 10, we can revisit this. I suspect we'll have to make > -fno-optimize-sibling-calls the default for GCC 10 as well; while we might be > able to help LAPACK maintainers fix LAPACKE there's in this timeframe there's > certainly a lot of other code out there with custom C-Fortran interfaces which > might be affected. I don't see how -fno-optimize-sibling-calls helps in a systematic way. It might obfuscate a specific example enough to make it work, but...?
