On Tue, 18 Oct 2022 16:46:07 +0200
Thomas Schwinge <tho...@codesourcery.com> wrote:
> Hi Julian!
>
> On 2022-10-14T13:38:56+0000, Julian Brown <jul...@codesourcery.com>
> 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.oacc-fortran/privatized-ref-2.f90
> > @@ -94,9 +94,7 @@ contains
> > !$acc parallel copy(array)
> > !$acc loop gang private(array) ! { dg-line l_loop[incr c_loop]
> > } ! { dg-note {variable 'i' in 'private' clause isn't candidate for
> > adjusting OpenACC privatization level: not addressable} "" { target
> > *-*-* } l_loop$c_loop }
> > - ! { dg-note {variable 'array\.[0-9]+' in 'private' clause is
> > candidate for adjusting OpenACC privatization level} "" { target
> > *-*-* } l_loop$c_loop }
> > - ! { dg-note {variable 'array\.[0-9]+' ought to be adjusted for
> > OpenACC privatization level: 'gang'} "" { target *-*-* }
> > l_loop$c_loop }
> > - ! { dg-note {variable 'array\.[0-9]+' adjusted for OpenACC
> > privatization level: 'gang'} "" { target { ! {
> > openacc_host_selected || { openacc_nvidia_accel_selected &&
> > __OPTIMIZE__ } } } } l_loop$c_loop }
> > + ! { dg-note {variable 'array\.[0-9]+' in 'private' clause
> > isn't candidate for adjusting OpenACC privatization level:
> > artificial} "" { target *-*-* } l_loop$c_loop } ! { dg-message
> > {sorry, unimplemented: target cannot support alloca} PR65181 {
> > target openacc_nvidia_accel_selected } l_loop$c_loop } do i = 1, 10
> > array(i) = 9*i
>
> ... here. Note "variable 'array\.[0-9]+' in 'private' clause";
> everywhere else we have "declared in block".
>
> As part of your verification, have you already looked into whether the
> new behavior is correct here, or does this one need to continue to be
> "adjusted for OpenACC privatization level: 'gang'"? If the latter,
> should we check 'if (res && block && DECL_ARTIFICIAL (decl))' instead
> of 'if (res && DECL_ARTIFICIAL (decl))', or is there some wrong
> setting of 'DECL_ARTIFICIAL' -- or are we maybe looking at an
> inappropriate 'decl'? (Thinking of commit
> r12-7580-g7a5e036b61aa088e6b8564bc9383d37dfbb4801e "[OpenACC
> privatization] Analyze 'lookup_decl'-translated DECL [PR90115,
> PR102330, PR104774]", for example.)
I haven't looked in detail, but it seems 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 are probably subtleties I'm not aware of...
HTH,
Julian
