On 09.12.20 12:36, Thomas Schwinge wrote:
I'm confirming that it seems to work (that is, doesn't seem to cause any obvious interference); OK to verify/document that as in the attached "Add 'gfortran.dg/goacc-gomp/omp-scan-1-if_present.f90'"?
I don't think the testcase is useful, but I wouldn't veto it. However, I think the comment change is completely misleading. And additionally the testcase misses the point in terms what happens internally. Namely: !$acc update ... if_present gets translated into an gfc_code->op == EXEC_OACC_UPDATE gfc_code->code->ext.omp_clauses->if_present = true While !$omp scan ... gets translated into gfc_code->op == EXEC_OMP_SCAN which for a short time sets: gfc_code->code->ext.omp_clauses->if_present = true (And those are different gfc_code variables.) If we worry about this, we should also add a testcase that for !$acc update host(a) !$acc update self(b) if_present checking that the first 'acc' does not have if_present set. That it is also almost impossible to generate a compilable testcase – due to the restrictions of 'omp scan' but also because '!$acc update' cannot appear in an 'omp do' loop — comes on top of this but focusing on the testcase is really a red herring. Tobias PS: Unsetting 'if_present' for OMP_SCAN makes sense as otherwise trans-openmp.c creates an OMP_CLAUSE_IF_PRESENT clause, which may cause problems in the middle end. But that's completely independent of -fopenacc and !$acc. ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
