https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On November 23, 2017 6:30:34 PM GMT+01:00, "dominiq at lps dot ens.fr" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 > >--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> >--- >> As I said in the other bug we're seeing >> >> real(real64), dimension(nsplit) :: tmp >> >> as "shared" amongst the outer loop iterations. >> >> ... >> >> Not sure if you need to mark compute somehow to avoid this >> and the testcase is invalid fortran or if the frontend is at fault. > >IMO the testcase is valid fortran and, with my naive view of arrays >returned by >a function, the returned array should be private to the function. > >If I do the following changes > >... > real(real64), dimension(nsplit) :: pi, pik >... > do concurrent (i = 1:nsplit) > pik = compute( low(i), high(i) ) > pi(i) = sum(pik) > end do >... > >the code works as expected, at least for my limited testing. I looked at the IL from the Fortran FE and it clearly uses a single memory area for tmp for each outer loop iteration. That is, the memory is allocated by the caller. > >Do you understand why the code is not parallelized with >-ftree-parallelize-loops=4? Because the outer loop has four iterations and we statically require at least two per thread for outer loops. Richard.
