Hi! This is about communicating environment variables to the target for use in (libgomp) execution testing. In particular, the ACC_DEVICE_TYPE environment variable to select at runtime which offloading device to use. I had an ugly hack for that particular case, <http://news.gmane.org/find-root.php?message_id=%3C87iobwjfh1.fsf%40schwinge.name%3E>, but this is clearly not acceptable for commit.
On Thu, 14 May 2015 10:54:07 +0200, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, May 14, 2015 at 10:05:36AM +0200, Jakub Jelinek wrote: > > On Thu, May 14, 2015 at 12:10:50AM +0200, Thomas Schwinge wrote: > > > No doubt, looking forward to the day, when this can be reverted. > > > > > > libgomp/ > > > * env.c (initialize_env): Remove static attribute. > > > * libgomp.map (INTERNAL): Export initialize_env. > > > > Ugh. While you achieve what you want for the remote board cases, > > doesn't this completely break all OpenMP and OpenACC programs not built > > as part of the testsuite, because initialize_env won't be called in that > > case? (No, it doesn't break them; initialize_env is still called as before.) > Can't you just tweak *.exp files so that if dg-set-target-env-var is used > or some forced env var is added to the same list through other means, The patch adding that machinery, <http://news.gmane.org/find-root.php?message_id=%3C20121203193645.GD2315%40tucnak.redhat.com%3E> and thereabouts, just bails out for remote testing: the wrapper gcc/testsuite/lib/gcc-dg.exp:${tool}_load does »if { [is_remote target] } { return [list "unsupported" ""]« if environment variables are to be set, so test cases using dg-set-target-env-var are currently UNSUPPORTED in case of remote testing. > you invoke on the remo[t]e side env VAR1=val1 VAR2=val2 program arguments > instead of program arguments ? Yes, using a wrapper for the program invocation is an idea I had before, and also what Mike suggested in <http://news.gmane.org/find-root.php?message_id=%3C3147BE85-53E5-4E23-8887-6CA3D780431E%40comcast.net%3E>, but implementing that is not exactly trivial as far as I can tell. First, such a "env wrapper" is appropriate only for a certain class of target systems (only for "Unix" systems, or something like that), so we need a way (perferably automatic) to determine that property of the target. We can't do the wrapping in gcc/testsuite/lib/gcc-dg.exp:${tool}_load because when that invokes the original *_load routine (save_${tool}_load), its program argument will be checked for existence, to be downloaded to the target, which in our case then would be the wrapper executable (/usr/bin/env), which doesn't make sense/is not correct/won't work. Leaving aside the option of DejaGnu modifications as mentioned by Mike (difficult to coordinate, deploy...), it seems that we can achieve what we want by wrapping DejaGnu's remote_exec and remote_spawn procedures in gcc/testsuite/lib/gcc-dg.exp, where we then can prepend the "env wrapper" to the program and commandline strings, respectively. But probably, doing such wrapping if not exactly elegant, and apart from the question whether it is appropriate to use an "env wrapper" for the execution at stake (only for "Unix" systems), there is also a new problem: these procedures are also invoked for host compilation, for example, in which case we also don't want to set the "env wrapper". Any clever ideas? I can also back out, and follow the other idea that I had, <http://news.gmane.org/find-root.php?message_id=%3C87sic2zpsz.fsf%40schwinge.name%3E>, <http://news.gmane.org/find-root.php?message_id=%3C8761ekpu1h.fsf%40schwinge.name%3E>, about ditching usage of the ACC_DEVICE_TYPE environment variable during testing, and instead use -foffload=[...] during compilation to only include offloading code in the executable for one particular device, so that the runtime then only can offload to this particular device. But of course, that won't solve the general problem (other execution tests that currently are UNSUPPORTED because of dg-set-target-env-var usage). Grüße, Thomas
signature.asc
Description: PGP signature
