The bug in PR70289 is an assertion failure triggered by a static variable used inside an offloaded acc region which doesn't have a data clause associated with it. Basically, that static variable ends up in a different lto partition, which was not streamed to the offloaded compiler. I'm not sure if we should try to replicate the static storage in the offloaded regions, but it probably doesn't make sense in a parallel environment anyway. My solution to this problem was to teach the fortran front end to create a data clause for each reduction variable it encounters. Furthermore, I've decided to update the semantics of the acc parallel reduction clause such that gfortran will emit an error when a reduction variable is private or firstprivate (note that an acc loop reduction still works with private and firstprivate reductions, just not acc parallel reductions). The second change is to emit a warning when an incompatible data clause is used with a reduction, and promote that data clause to a present_or_copy. My rationale behind the promotion is, you cannot have a copyin reduction variable because the original variable on the host will not be updated. Similarly, you cannot have a copyout reduction variable because the reduction operator is supposed to combine the results of the reduction with the original reduction variable, but in copyout the original variable is not initialized on the accelerator. But perhaps the copyout rule is too strict? Tom and I are still working with the OpenACC technical committee to get some clarification on how the reduction value should behave with respect to data movement. In the meantime, I wanted to see if this type of solution would be appropriate for trunk. I was trying to get this to work in the gimplifier so that one patch could resolve the problem for all of the front ends, but that was happening too late. Especially for reference types. By the way, we will also benefit from this patch too . If not for these reduction, but for global acc variables which haven't been properly declared. Cesar