On 04/01/2016 08:17 AM, Jakub Jelinek wrote:
> On Fri, Apr 01, 2016 at 08:07:24AM -0700, Cesar Philippidis wrote:
>> On 04/01/2016 07:56 AM, Jakub Jelinek wrote:
>>> On Fri, Apr 01, 2016 at 07:49:16AM -0700, Cesar Philippidis wrote:
>>>> 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.
>>>
>>> Is this really Fortran specific?  I'd expect the diagnostics to be in
>>> gimplify.c and handle it for all 3 FEs...
>>
>> By the time the variable reaches the gimplifier, the reduction variable
>> may no longer match the ones inside the data clause. E.g. consider this
>> directive inside a fortran subroutine:
>>
>>   !$acc parallel copyout(temp) reduction(+:temp)
>>
>> The gimplifier would see something like:
>>
>>   map(force_from:*temp.2 [len: 4]) map(alloc:temp [pointer assign, bias:
>> 0]) reduction(+:temp)
>>
>> At this point, unless I'm mistaken, it would be difficult to tell if
>> temp.2 is a pointer to the same temp in the reduction. Maybe I'm missing
>> something?
> 
> All the info is still there, and this wouldn't be the only case where
> we rely on exact clause ordering.  I think that is still much better than

The gimplify approach didn't turn out to be that bad after all. Is this
patch ok for trunk? It fixes the problem for all fo the FEs.

Cesar