[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85129

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> I. trunk
> 
> The GOMP_OPENACC_DIM environment variable is not documented (it should have
> an entry in libgomp.texi at 'OpenACC Environment Variables').

Atm, in trunk, fopenacc-dim does not yet support the '-' syntax, so the only
dimension that GOMP_OPENACC_DIM can influence is gang.

It probably doesn't make any sense to document GOMP_OPENACC_DIM until it's
fully functioning.

[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85129

--- Comment #4 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #3)
> (In reply to Tom de Vries from comment #2)
> > GOMP_OPENACC_DIM seems to be the odd one here, and we should document
> > the non-standard behaviour that it supports being set in main using setenv.
> 
> Amongst other things, in
>  I
> wondered whether "GOMP_OPENACC_DIM parsing conceptually belongs into generic
> libgomp code, instead of the nvptx plugin.  (But [...] currently, the nvptx
> plugin is the only one supporting/using it.)".
> 

Ack. Filed PR85411 - "[openacc] Move GOMP_OPENACC_DIM parsing out of nvptx
plugin"

[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85129

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-10
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #2)
> GOMP_OPENACC_DIM seems to be the odd one here, and we should document
> the non-standard behaviour that it supports being set in main using setenv.

Amongst other things, in
 I
wondered whether "GOMP_OPENACC_DIM parsing conceptually belongs into generic
libgomp code, instead of the nvptx plugin.  (But [...] currently, the nvptx
plugin is the only one supporting/using it.)".

So, I'm not sure we should really document now and thus set the expectation
that 'setenv("GOMP_OPENACC_DIM")' will continue to work as it does now.

[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85129

--- Comment #2 from Tom de Vries  ---
> There are two test-cases excercising GOMP_OPENACC_DIM (using setenv rather
> than dg-set-target-env-var, to allow remote testing setups to work where
> dg-set-target-env-var is broken)

Actually, using setenv as first stmt in main works for GOMP_OPENACC_DIM,
because the value is read for the first time after that, in nvptx_exec.

But f.i. GOMP_DEBUG is read in initialize_env, which has the constructor
attribute, which "causes the function to be called automatically before
execution enters main ()". So there, using setenv doesn't work. Same goes for
ACC_DEVICE_TYPE and ACC_DEVICE_NUM, which are also set in initialize_env.

So, GOMP_OPENACC_DIM seems to be the odd one here, and we should document the
non-standard behaviour that it supports being set in main using setenv.

[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85129

Tom de Vries  changed:

   What|Removed |Added

   Keywords||documentation
 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from Tom de Vries  ---
> When deferring
> to runtime, the environment variable @var{GOMP_OPENACC_DIM} can be set.
> It has the same format as the option value, except that '-' is not
> permitted.

Thinking about it some more, this doesn't make sense to me.

If we don't specify GOMP_OPENACC_DIM, then libgomp decides on the dimensions
that haven't been decided on yet.

So if '-' means: let libgomp decide, than surely not specifying
GOMP_OPENACC_DIM is the same as specifying GOMP_OPENACC_DIM="-:-:-"

I think it's better to keep the syntax equal between fopenacc-dim and
GOMP_OPENACC_DIM.