Re: adding an argument for test execution in testsuite
It is unfortunate that UPC program cannot use dg-additional-sources
as we would need to change our run-time to support this option. By the
time we reach "main" run-time is already initialized to support specified
number of threads. One of the options might be to define a default number
of threads to run if number is not specified.
Anyway, I spent a little bit more time on this and was able to create a
wrapper for "upc_load" function the same way it is done in gcc-dg.exp
(renaming the old upc_load into prev_upc_load). Wrapper adds the necessary
flags for dynamic environment. Notice that ${tool}_load already accepts
arguments that can be passed to the program.
Nenad
On 5/4/11 3:32 PM, Janis Johnson wrote:
On 05/04/2011 11:21 AM, Nenad Vukicevic wrote:
It seems that I fixed my problem by defining remote_spawn
procedure (and fixing the order of loading libraries :) ) in my
own upc-dg.exp file and adding a line to it that append
additional arguments to the command line: "append commandline
$upc_run_arguments".
global $upc_run_arguments is getting set before dg-test is being
called. I used a simple string compare to see if dynamic
threads are required. So far it works as expected.
Working "so far" shouldn't be good enough, especially if your test will
be run for a variety of targets.
Presumably you don't really need the number of threads to be specified
on the command line, you just need for it to look as if it were
specified at run time. You could, for example, define it in a second
source file included in the test via dg-additional-sources and use it
from a global variable or call a function to get it.
Janis
Re: adding an argument for test execution in testsuite
On 05/04/2011 11:21 AM, Nenad Vukicevic wrote: > It seems that I fixed my problem by defining remote_spawn > procedure (and fixing the order of loading libraries :) ) in my > own upc-dg.exp file and adding a line to it that append > additional arguments to the command line: "append commandline > $upc_run_arguments". > > global $upc_run_arguments is getting set before dg-test is being > called. I used a simple string compare to see if dynamic > threads are required. So far it works as expected. Working "so far" shouldn't be good enough, especially if your test will be run for a variety of targets. Presumably you don't really need the number of threads to be specified on the command line, you just need for it to look as if it were specified at run time. You could, for example, define it in a second source file included in the test via dg-additional-sources and use it from a global variable or call a function to get it. Janis
Re: adding an argument for test execution in testsuite
It seems that I fixed my problem by defining remote_spawn procedure (and fixing the order of loading libraries :) ) in my own upc-dg.exp file and adding a line to it that append additional arguments to the command line: "append commandline $upc_run_arguments". global $upc_run_arguments is getting set before dg-test is being called. I used a simple string compare to see if dynamic threads are required. So far it works as expected. Thank you. Nenad On 5/4/2011 10:18 AM, Ian Lance Taylor wrote: Nenad Vukicevic writes: Thank you for your response. I am trying to write some tests for GUPC that have two modes of compilation: static and dynamic. In static environment you specify number of threads you want to run in compile time, while in dynamic you specify it when you run the program (prog -n4 args). We have to test both modes and I was thinking of checking the compile arguments and passing -n4 to _load procedure for dynamic case. It could be that I can accomplish this with a new target in dejagnu. I tried defining upc_load() procedure (the same way gnat_load() is defined) and possible add all the necessary code to it, but was not successful in dejagnu calling it. Sorry, I can't help you there. DejaGNU is just awful. It has only one thing going for it, which is that it mostly works. In every other respect it is worse than having no test harness at all. Unfortunately that one advantage currently outweighs the disadvantages. Ian
Re: adding an argument for test execution in testsuite
Nenad Vukicevic writes: > Thank you for your response. I am trying to write some tests > for GUPC that have two modes of compilation: static and dynamic. In > static environment you specify number of threads you want to run in > compile time, while in dynamic you specify it when you run the > program (prog -n4 args). We have to test both modes and I was thinking > of checking the compile arguments and passing -n4 to _load procedure > for dynamic case. It could be that I can accomplish this with a new > target in dejagnu. > > I tried defining upc_load() procedure (the same way gnat_load() is defined) > and possible add all the necessary code to it, but was not successful in > dejagnu calling it. Sorry, I can't help you there. DejaGNU is just awful. It has only one thing going for it, which is that it mostly works. In every other respect it is worse than having no test harness at all. Unfortunately that one advantage currently outweighs the disadvantages. Ian
Re: adding an argument for test execution in testsuite
On 5/3/2011 3:47 PM, Ian Lance Taylor wrote: There is no support for passing options to a test in the dg framework. You would have to write your own Tcl code to do that. Note that such tests are somewhat discouraged because not all remote execution environments support passing command line arguments. It's OK to do it if the command line argument is optional or if the test can never work on an embedded system anyhow. Ian Thank you for your response. I am trying to write some tests for GUPC that have two modes of compilation: static and dynamic. In static environment you specify number of threads you want to run in compile time, while in dynamic you specify it when you run the program (prog -n4 args). We have to test both modes and I was thinking of checking the compile arguments and passing -n4 to _load procedure for dynamic case. It could be that I can accomplish this with a new target in dejagnu. I tried defining upc_load() procedure (the same way gnat_load() is defined) and possible add all the necessary code to it, but was not successful in dejagnu calling it. Nenad
Re: adding an argument for test execution in testsuite
Nenad Vukicevic writes: > Is it possible to add an argument to the test in the > execution phase of the testsuite? I am looking into > some test cases where number of threads to run must > be provided on the invocation line of the test if not > specified during the test compilation. Something that > is similar to "dg-skip-if" syntax but would add a run-time > option if there is a match. There is no support for passing options to a test in the dg framework. You would have to write your own Tcl code to do that. Note that such tests are somewhat discouraged because not all remote execution environments support passing command line arguments. It's OK to do it if the command line argument is optional or if the test can never work on an embedded system anyhow. Ian
adding an argument for test execution in testsuite
Is it possible to add an argument to the test in the execution phase of the testsuite? I am looking into some test cases where number of threads to run must be provided on the invocation line of the test if not specified during the test compilation. Something that is similar to "dg-skip-if" syntax but would add a run-time option if there is a match. Thanks, Nenad
