https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94358
--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- (In reply to Thomas Schwinge from comment #0) > The original test case, 'gcc/testsuite/gfortran.dg/goacc/default_none.f95', > had already gotten committed (unmodified) to trunk in r229832 (commit > ef014f95d542ae7b18cb4150cbb1f1ef68160f7b, 2015-11-06) -- so presumably > didn't exhibit the original 'default(none)' problem any more. > > That's presumably due to > <http://mid.mail-archive.com/564378BB.8050400@acm.org> "open acc default > data attribute", where per the "fortran FE" comment, the new > 'DECL_ARTIFICIAL' handling might indeed be the reason why we're no longer > seeing the original 'default(none)' correctness issue. So the first thing (please, separately from other changes/patches mentioned here), is to make sure that these (supposedly) 'DECL_ARTIFICIAL' objects generated by the Fortran front end do play well regarding PR94876 "[OpenACC] Unhelpful mapping for 'DECL_ARTIFICIAL' inside OpenACC 'kernels' regions". Assuming that the Fortran front end does generate 'DECL_ARTIFICIAL' objects which instead of 'firstprivate' clauses will then get 'copy' clauses generated for OpenACC 'kernels' constructs, and the Fortran front end supposedly generates code to initialize these 'DECL_ARTIFICIAL' objects inside the offloaded region, we'd then have race-conditions, with all device threads writing into the same global memory concurrently? Tobias, as a first step, can you please provide an exemplary Fortran test case that shows some cases of what code the Fortran front end generates to calculare array lower and upper bounds etc., for a multi-level OpenACC gang, worker, vector loop?
