http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218
--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-21 08:41:21 UTC --- (In reply to comment #14) > Tobias, Why did you mark this PR with the "wrong-code" keyword? Because it generates "wrong-code" and I wasn't completely convinced that there is no bug lurking in implicit_pure. Thus, for me the status is an "unconfirmed" bug which would be - if confirmed - a wrong-code 4.7 regression. However, it looks as if the code is invalid and so far I didn't come up with something valid which gets wrongly treated. * * * (In reply to comment #11) > The code does memory management similar to that required by > TR15581 for allocatable DT components and allocatable function > results, but it also has to work for compilers that do not > support TR15581. It does so by overloading everything needed. I think that by now most compilers support TR 15581, thus, you could consider to solve the issue by changing the code to TR 15581. At the moment you have code which might work by chance with some compilers but fail with others since it is invalid. > > I would advise you to fix your code to > > be standard-conforming. > > Do you have a suggestion without introducing a memory leak? Unfortunately not. The mix of having to use INTENT(IN) because of OPERATOR(...) combined with the need to modify the argument looks extremely fragile and - as this issue shows - also breaks in practice. In principle, using TARGET, you could allow the variable to alias - but only if you do not use INTENT(IN) ... I think there is no simple way out, if (and only if) you need to be compatible to pre-TR15581 compilers. One other suggestion would be to compile the code with -O0. For gfortran, I do not see any possibility to "fix" is, which doesn't cause severe performance regressions. The problem is not just the implicit_pure attribute or the front-end optimization. The Fortran front end also passes the INTENT(IN) to the middle end, which allows also the middle end to certain optimizations. And, here, the user has explicitly entered the INTENT(IN) himself. Alias issues are one of the most important problems which hamper optimization. Thus, compilers try to make use of anything in the standard which rules out aliasing. If they can't, temporary arrays have to be introduced, code may not be optimized away, loop vectorization might be impossible etc. I think one of the strengths of gfortran is that it makes a lot of effort to avoid array temporaries and similar alias related issues. Thus, unless a practical suggestion how gfortran should be changed comes up - or a scenario is found where gfortran generates invalid code for a valid program, I am inclined to close the bug as INVALID, which would be in line of the comments of Thomas and Steve.
