http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #8 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> --- (In reply to Marc Glisse from comment #7) > (In reply to Joost VandeVondele from comment #6) > > Marc, I think your recently posted patch: > > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01049.html > > could fix the problem with the testcase subroutine S1, even though 'moving > > allocations out of loops' is more or less a side effect. > > I don't speak fortran fluently so I tried compiling S1 with an unpatched > compiler and -O2 -fdump-tree-optimized, but I don't see any call to malloc > in there. Could you explain, with references to a dump, what the internal > functions mean and where my patch might help? Marc, looks like the fortran FE changed a lot since this bug was filed, and there is no explicit allocate anymore, in fact the variable is created on stack by the frontend... this is controlled by -fmax-stack-var-size=0 (putting it to zero, will yield your __builtin_malloc() that I recalled, in the PR38318.f90.003t.original dump). You have a precedent for getting the a reasonable size (32768 for fortran). The _gfortran_internal_(un)pack is a fortran FE thing, that guarantees that memory is contiguous... clearly a missed frontend optimization in this case. So now, the proper testcase would be: > cat PR38318-3.f90 SUBROUTINE S1(N,A) REAL :: A(3) REAL, DIMENSION(:), ALLOCATABLE :: B DO I=1,N ALLOCATE(B(3)) B=-A CALL S2(B) DEALLOCATE(B) ENDDO END SUBROUTINE which really should contain any call to _gfortran_runtime_error_at, _gfortran_os_error, __builtin_malloc, __builtin_free if all were perfect, and certainly not in the loop
