This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |