[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #7 from Jakub Jelinek --- That is not that surprising. As mentioned in the linked in PR99928, that behavior is there only in OpenMP 5.0 and wasn't like that in OpenMP 4.5 and earlier; in OpenMP 4.5 you really need separate target (or target teams) with explicit map clause and then distribute ... with reduction. And this part of OpenMP 5.0 was only implemented in GCC starting with GCC 12, older versions supported the 4.5 behavior.
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #6 from tommelt --- Thank you. Interestingly, I tried your suggestion: "!$omp target teams distribute parallel do simd if(target:is_GPU) reduction(max:max_diff) collapse(2)" It works for gfortran v 12.2.0 but it does not work for: * gfortran v 11.3.0 or; * gfortran v 10.3.0
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- This is a user error. The OpenMP standard makes reduction vars mapped on target only on combined constructs with the target construct, which is not the case here. If you'd use !$omp target teams distribute parallel do simd if(target:is_GPU) reduction(max:max_diff) collapse(2) then max_diff would be mapped. But as it is on a different constructs, the standard rules apply there and max_diff is firstprivatized instead (as it is scalar, no defaultmap clause is used etc.). So, if that isn't what you want, you need to map it explicitly map(tofrom:max_diff) or so on the target.
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #4 from Thomas Meltzer --- Thanks adding map(max_diff) works for me but my guess is that this should not be required and there is a potential bug.
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Thomas Meltzer from comment #1) > Could be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 but I > am not sure. In my case the GPU offloading should be ignored. Replacing the line !$omp target teams if(is_GPU) !< comment this by !$omp target teams if(is_GPU) map(max_diff) seems to make a difference for me. So it might be related to pr99928.
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp --- Comment #2 from anlauf at gcc dot gnu.org --- If I compile the code with -g -fsanitize=thread, I see a data race in the second loop nest pointing to a possible issue with the reduction.
[Bug fortran/109701] I have a MWE where an omp reduction breaks if I add the option for GPU offloading (even if it isn't used).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701 --- Comment #1 from Thomas Meltzer --- Could be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 but I am not sure. In my case the GPU offloading should be ignored.
