Hi!
On 2022-10-18T16:46:07+0200, Thomas Schwinge wrote:
> On 2022-10-14T13:38:56+, Julian Brown wrote:
>> This patch prevents compiler-generated artificial variables from being
>> treated as privatization candidates for OpenACC.
>>
>> The rationale is that e.g. "gang-private" variables actua
s to me that the "artificial"
>> flag isn't appropriate for that decl, which is (derived from?) a
>> user-visible symbol. So, I'm not sure what's going on there (and yes
>> the commit you mention looks like it could be relevant, I think?).
>> There ar
Hi!
On 2022-10-18T15:59:24+0100, Julian Brown wrote:
> On Tue, 18 Oct 2022 16:46:07 +0200 Thomas Schwinge
> wrote:
>> On 2022-10-14T13:38:56+, Julian Brown wrote:
>> ..., but to my surprised, that did fire in one occasion:
>>
>> > --- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref
On Tue, 18 Oct 2022 16:46:07 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2022-10-14T13:38:56+, Julian Brown
> wrote:
> ..., but to my surprised, that did fire in one occasion:
>
> > --- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
> > +++ b/libgomp/testsuite/libgomp.o
Hi Julian!
On 2022-10-14T13:38:56+, Julian Brown wrote:
> This patch prevents compiler-generated artificial variables from being
> treated as privatization candidates for OpenACC.
>
> The rationale is that e.g. "gang-private" variables actually must be
> shared by each worker and vector spawn
This patch prevents compiler-generated artificial variables from being
treated as privatization candidates for OpenACC.
The rationale is that e.g. "gang-private" variables actually must be
shared by each worker and vector spawned within a particular gang, but
that sharing is not necessary for any
