Re: [gomp] Fix a couple of global var handling bugs, add firstprivate+lastprivate barrier (PR c++/26943)

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, May 01, 2006 at 12:47:03PM -0700, Richard Henderson wrote:
> On Mon, May 01, 2006 at 01:06:11PM -0400, Jakub Jelinek wrote:
> > +	  /* Global variables don't need to be copied,
> > +	     the receiver side will use them directly.
> > +	     For nested contexts we unfortunately don't know
> > +	     yet whether it will be a global variable or not.  */
> > +	  if (! ctx->is_nested && is_global_var (decl))
> > +	    break;
> >  	  if (! TREE_READONLY (decl)
> 
> What's the test case for this?  Just testing is_nested doesn't

libgomp.c/pr26943-1.c shows why not emitting the code for global vars is
desirable.  libgomp.c/pr26943-4.c is where is_global_var (decl) is true, yet
the variable is not global in the end.
It is true that in some cases we know where we stand even in the is_nested
case already during scanning, so perhaps some maybe_lookup_decl_in_outer_ctx
could DTRT.  But I think e.g. if a variable is private only because it is
used somewhere as iteration var or similar cases we might know for sure
only once all the scanning is done.  Worst case we just allocate an unused
slot in the .omp_data_* structure.
Will look tomorrow at maybe_lookup_decl_in_outer_ctx.

> seem quite right.  I should think that we ought to be able to
> tell, at some point whether it is or isn't.  Perhaps a variant
> of lookup_decl_in_outer_ctx?

	Jakub