https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #9 from vries at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #8) > IMNSHO it is much better to accurately describe the builtins to the aliasing > code etc. over adding ugly hacks like the tailcall one, or postponing > expansion till later etc. We're discussing two issues now in the PR: GOACC_data_start/end and GOACC_parallel. The issues are related because in both cases we're trying to deal with a GOACC builtin acting as an optimization barrier for the kernels region. The issues are also different because for GOACC_parallel there's an associated code block, and for GOACC_data_start/end there isn't. I'm working on fixing the GOACC_data_start/end issue by adding the omp_dara_arr argument of GOACC_data_start to GOACC_data_end and adding fnspec ".r" to GOACC_data_end. AFAIU, you agree with that approach. The GOACC_parallel is more tricky. I don't see what kind of fnspec for GOACC_parallel could fix this. The only other potential solution I see besides postponing expansion of the parallel region is ipa_pta. But that's apparently not production ready yet (PR46032 comment 19). Any other ideas?
