https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #16 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #15) > (In reply to anlauf from comment #14) > > (In reply to Thomas Koenig from comment #13) > > > I think we have quite a few bad choices here, each with different > > > drawbacks. > > > I don't think we should do nothing, or pessimize existing code. > > > > > > Hmm... what about adding an option which sets ASYNCHRONOUS on every > > > assumed size and explicit size (i.e. F77-style) arguments? This > > > would restrict the effect to those users who explicitly ask for it. > > > > Why adding an option? Why not doing it for all cases where SRA kicks in? > > Because that would pessimize existing code (don't know how > much it would matter, but I do not think we would like to > have escaping pointers be the default. This would mean that > the compiler would have to assume that, in > > call foo(x) > call bar(y) > > the call to bar can change x, and that is not what Fortran > is about. IIRC, Fortran 77 did not have any idea of code that is not Fortran, and there was quite some code where foo and bar were either non-Fortran, or wrappers to something that is not Fortran. > > > > And does assumed size really fail, or only explicit size? > > Assumed size is > > SUBROUTINE FOO(X) > REAL X(*) > > It took me a long time to keep the terminology separated > from assumed shape, which is > > subroutine foo(x) > real, dimension(:) :: x I do know what explicit size, assumed size, and assumed shape are. But have a look at the generated code for the CG example. With SRA enabled, it looks horrible for the explicit size. And then compare the code with ASYNCHRONOUS set, or with the argument having variable size. I actually doubt that there is a significant performance impact around that particular call. > I browsed the github repository for a bit, but I didn't find the > (erroneous) declarations. Does anybody have them? > > > > > > > And no, it would not be elegant. > > > > That's why I think it should either not be an option, or an option that > > is on by default. > > I disagree (see above). Alright, then we agree that we disagree. I'd rather have a compiler that gives "right" answers for rather standard options, meaning being backwards compatible for ancient code. Note: there was no ASYNCHRONOUS in F77, no regular pointers, no aggregates, etc. So there was no "standard conforming way" back then, and we cannot blame the MPI people for it.
