openmp/testsuite/README_OpenMP_Validation_Suite - toolchain/llvm-project - Gitiles

  ============================================================================
 |                   OpenMP Validation Suite  V 3.0                           |
 |              High Performance Computing Center, Stuttgart                  |
 |       High Performance Computing and Tools, University of Houston          |
 |                              Jan. 2012                                     |
  ============================================================================


 TABLE OF CONTENTS

 I    	INTRODUCTION
 I.1.	  Aims and general function
 I.2. 	  Files and directories

 II		USAGE
 II.1.	  First run with make
 II.2	  Where to search for results
 II.3.	  Using the runtest script

 III		Adding and modifying tests
 III.1.	  The template structure

 IV		Known Issues and Workaround

 V       Contact and Support

 ------------------------------------------------------------------------------

 I.  INTRODUCTION
 ==============================================================================

 I.1.  Aims and general function
 --------------------------------

 The OpenMP validation suite is designed to verify the correct implementation
 of OpenMP in compilers. It is capable of checking Fortran as well as c
 compiler.

 Testing the implementation is based on statistics. Each directive is tested
 by computing and verifying the result with the already known value. In most
 cases a wrong implementation can result in the right values. So the tests are
 run several times.

 Additionally, the validation suite creates so called crosstests for each
 directive. These are tests in which either the directive is missing or used
 with different arguments. If this so called crosstest fails, this indicates
 strongly that the previous test is capable of testing the directive.

 Lastly, an orphaned test is also run to determine if the directive being
 tested is able to correctly run when 'orphaned' from the main function.
 Essentially, the directive's code is placed into its own function which is
 called during execution of the main function and often inside a parallel
 region.


 I.2.  Files and directories
 ----------------------------


 d c                         directory containing the templates for the c tests
 d fortran                   directory containing the templates for the Fortran
                             tests
   Makefile                  Makefile containing options for compilation
   common_utility.f
   omp_my_sleep.h            thread save sleep function
   omp_testsuite.f           Fortran header file
   omp_testsuite.h           autogenerated c-header file
   ompts-c.conf              configuration file for the c tests about how often
                             the tests shall be executed or how large the loop size
                             is
   ompts_makeHeader.pl	    perl module for automatically generation of an up
                             to date header file
   ompts_parserFunctions.pm	perl module containing general functions for
 				            the parser.pl script
   ompts_parser.pl	        script for generating the source code out of the templates
   ompts_standaloneProc.c	framework for the c tests
   ompts_standaloneProc.f	framework for the Fortran tests
   README		            the README file you've already found ;-)
   LICENSE                   contains license information
   runtest.pl		        the frame program of the test suite
   testlist-f.txt	        test list containing the available tests for Fortran
   testlist-c.txt	        test list containing the available tests for c


 ------------------------------------------------------------------------------

 II.  USAGE
 ==============================================================================


 II.1. First run with make
 --------------------------


 You can do a first simple run of the testsuite only after one step of
 configuration:

 1) Modify the ompts.conf and ompts-c.conf file, change the number of threads
 and number of repetitions of each test.

 2) Modify the Makefile, uncommenting the CC/FC and CFLAGS/FFLAGS variables for
 the compiler of your choice.

 And now you can run the testsuite either for a C compiler with:

 >	make ctest

 or for a Fortran compiler with:

 >	make ftest


 II.2. Running custom tests
 --------------------------


 In order to run single tests or custom groups of tests, two make commmands
 are defined: make stest and make fstest. These two command reference the file
 customtest.txt when looking for a testlist to use. Simply edit customtest.txt
 to include the desired test or tests. If customtest.txt contains c tests,

 >      make stest

 or for fortran tests

 >      make fstest

 In order to change the number of threads used in the tests, simply edit the
 Makefile variables MINTHREADS and MAXTHREADS. By default, they are configured
 to use 2 threads. To change the number of times each test is run, for c tests
 edit the REPETITIONS variable in the file ompts-c.conf. The LOOPCOUNT and
 SLEEPTIME variables can also be changed here. For fortran tests, edit the file
 omp_testsuite.f to change both the LOOPCOUNT and the number of times each test
 is run.


 II.3. Understanding the results
 ---------------------------------


 When running the testsuite the results will be shown on the screen.

 If you need the results for further purpose you can use the results.txt, which
 is a simple list containing the results for each directive
 in a single line. Each line starts with the name of the directive. Then follows
 the result of the test given in the percentage of the passed tests. If 100% of
 the tests passed successfully, the second number gives the result of the
 corresponding crosstest. Crosstests will only be run if the normal test passes
 with 100% accuracy. If a crosstest was not run or a test does not exist, it is
 denotated by a "-".
 After the results of the normal tests, there follow a series of tests in the
 orphaned mode. If there were no orphaned tests available this is shown by a "-".

 If you run the testsuite with different numbers of threads (e.g. using the
 runtest.pl script) the results are shown in blocks of 4 columns for each number
 of threads.

 If a test fails you can find more detailed information in the ompts.log,
 bin/c/*.out and *.log files. While the ompts.log file contains all compiler
 error messages for all tests, the *.out and *.log files contain detailed inforamtion
 on the execution process of the single tests.
 In the *.out files there are listed all the results of the single executions of
 the tests. In the *.log files there are error messages of the tests itself.


 II.4. Cleaning Up
 -----------------


 Because many files are generated for each tested directive, it is often necessary
 to clean the main directory after a battery of tests. To clean all generated files
 in the main directory including the results and log files,

 >     make clean


 To clean only the logs and out files,

 >     make cleanlogs

 To clean only the results,

 >     make cleanresults


 II.4. Using the runtest script
 -------------------------------


 So for special purpose you can use the runtest.pl script, which allows a lot
 more options for the execution process than the execution with make.

 Using the runtest.pl script is rather easy. You can use the the test suite only
 after two steps of modifications:

 1.) Modify the Makefile to your wishes choosing your compiler and the necessary
     compiler flags.
 2.) If necessary edit one of the test lists (testlist-c.txt) and comment out the
     tests you do not want to run using # at the beginning of a line. Testlists for Fortran end
     with -f.txt while test lists for c with -c.txt.

 And now you can run the test suite either for Fortran using
 	#	>  ./runtest.pl -lang=fortran -d=fortran testlist-f.txt
 or for c
 	#	>  ./runtest.pl -lang=c -d=c testlist-c.txt

 With the --help option you can show the complete list of options and their
 explanations.

 The test results are summarized in cresults or fresults.txt while *.log keep
 details for individual tests. There is also a file (ompts.log) keeping
 compilation information. (see section II.2 )

 If you don't want to test the directives in orphaned mode you can use the
 -norphan option. You also can use the runtest.pl script either to compile all
 tests or run compiled tests e.g. for cross compilation on other platforms. For
 this there are the options -norun and -nocompile.

 Happy testing!


 ------------------------------------------------------------------------------

 III.	How to add new tests / The structure of test templates
 ==============================================================================

 III.1  The template structure
 ------------------------------

 The test suite is based on templates so that you only have one file for test,
 crosstest and the orphaned versions of them.

 	A) Description of the template structure

 The syntax of the templates is much like xml. So each test begins with
 '<ompts:test>' and ends with '</ompts:test>'.

 In between there are several other blocks holding information:

 - <ompts:testdescription> </ompts:testdescription> In between this tag you can
   give a description on what the test checks and how it works.

 - <ompts:ompversion> </ompts:version> This tag is used to specify the
   OpenMP-version which includes the tested directive.

 - <ompts:directive> </ompts:directive> Used to specify the directive how it is
   called in the programming language.

 - <ompts:dependences> </ompts:dependences> With this tag you can specify other
   omp directives which are necessary for the correct execution of your test.
 The directives have to be listed by their directive names as it is called in
 the programming language. Multiple directives are separated by ','.

 - <ompts:testcode> </ompts:testcode> In this tag stands the whole source code
 for the test / crosstest.  Each test has to be written as a function. The
 syntax of the functions differs between C and Fortran: In C it has to take a
 file pointer 'FILE * logFile' and return an int. If the test has been passed
 successful it has to return a value unequal to 0. The file pointer can be used
 to write information into a log file.  In Fortran the function takes no
 argument and the function name must not exceed XX characters.  The return value
 has to be specified using the '<testfunctionname>' tags. It has to be 1 if the
 test succeeded and 0 if the test failed. For details see the example.

 To tell the test suite the name of your test function you have to enclose it
 into the '<ompts:testcode:functionname> </ompts:testcode:functionname>' tag.

 If there are differences between test and crosstest you can use the
 <ompts:check> </ompts:check> and <ompts:crosscheck> </ompts:crosscheck> tag.
 When generating the test the parser will use the code enclosed in
 <ompts:check> tags and cut out the code written in <ompts:crosscheck> tags. So
 you have two possibilities to write your template for test and crosstest: The
 first way you can write the complete code is to write the test in one
 <ompts:check> tag and later the crosstest in one <ompts:crosscheck> tag.  The
 second way is to write both tests only by enclosing differing parts in
 corresponding tags.

 The first method should be preferred if test and crosstest differ much from
 each other. The second e.g. if you only want to change a few options like
 replacing an omp singleprivate clause by an omp private clause or to cut out
 a directive like omp flush.  When you use the first way you have to take care
 of the function name! You have to declare it twice with
 <ompts:testcode:functionname>!

 - <ompts:orphan> </ompts:orphan> This tag can be used if you want to enable
   your test to check the directive in orphan regions, too.  The code enclosed
 in this part will be written to a separate function which will be called
 instead.  If you have variables which are used outside this region you have to
 declare them as global variables enclosed in an <ompts:orphan:vars> tag. For
 further information see the description of the <ompts:orphan:vars> tag.

 - <ompts:orphan:vars> </ompts:orphan:vars> This tag is used to specify global
   variables for an orphan region which allow the exchange of values between
 the main program and the orphaned functions. The usage differs between C and
 Fortran.  In C you have to use a single declaration for each variable. You can
 either declare all variables in one single or in several different regions. You
 must not initialize the variables inside!  In Fortran you have to put all
 declarations in one single tag. Because there exist no global variables as in
 C you have to use common blocks. For further information see the examples.

 III.2.  Adding tests to the test lists
 --------------------------------------

 After you have created a new test you have to add them to a testlist. Simply
 add the function name in a new Line into a file.


 ------------------------------------------------------------------------------


 IV.   Known Issues and Workaround
 ==============================================================================

 The Sun OS has a problem with the -maxdepth option on the 'make cleanall'
 command. This prevents the tests from being removed from the working directory
 and can cause problems with future tests. To remedy, edit the makefile line
 under the clean command:

      -rm [cf]test*.[cf] [cf]crosstest*.[cf] [cf]ctest*.[cf] [cf]orphan*.[cf]

 Change to:

      -rm [cf]test* [cf]crosstest* [cf]ctest* [cf]orphan*


 ------------------------------------------------------------------------------

 V.   Contact and Support
 ==============================================================================

 Contact: http://www.cs.uh.edu/~hpctools
	============================================================================
	\| OpenMP Validation Suite V 3.0 \|
	\| High Performance Computing Center, Stuttgart \|
	\| High Performance Computing and Tools, University of Houston \|
	\| Jan. 2012 \|
	============================================================================


	TABLE OF CONTENTS

	I INTRODUCTION
	I.1. Aims and general function
	I.2. Files and directories

	II USAGE
	II.1. First run with make
	II.2 Where to search for results
	II.3. Using the runtest script

	III Adding and modifying tests
	III.1. The template structure

	IV Known Issues and Workaround

	V Contact and Support

	------------------------------------------------------------------------------

	I. INTRODUCTION
	==============================================================================

	I.1. Aims and general function
	--------------------------------

	The OpenMP validation suite is designed to verify the correct implementation
	of OpenMP in compilers. It is capable of checking Fortran as well as c
	compiler.

	Testing the implementation is based on statistics. Each directive is tested
	by computing and verifying the result with the already known value. In most
	cases a wrong implementation can result in the right values. So the tests are
	run several times.

	Additionally, the validation suite creates so called crosstests for each
	directive. These are tests in which either the directive is missing or used
	with different arguments. If this so called crosstest fails, this indicates
	strongly that the previous test is capable of testing the directive.

	Lastly, an orphaned test is also run to determine if the directive being
	tested is able to correctly run when 'orphaned' from the main function.
	Essentially, the directive's code is placed into its own function which is
	called during execution of the main function and often inside a parallel
	region.


	I.2. Files and directories
	----------------------------


	d c directory containing the templates for the c tests
	d fortran directory containing the templates for the Fortran
	tests
	Makefile Makefile containing options for compilation
	common_utility.f
	omp_my_sleep.h thread save sleep function
	omp_testsuite.f Fortran header file
	omp_testsuite.h autogenerated c-header file
	ompts-c.conf configuration file for the c tests about how often
	the tests shall be executed or how large the loop size
	is
	ompts_makeHeader.pl perl module for automatically generation of an up
	to date header file
	ompts_parserFunctions.pm perl module containing general functions for
	the parser.pl script
	ompts_parser.pl script for generating the source code out of the templates
	ompts_standaloneProc.c framework for the c tests
	ompts_standaloneProc.f framework for the Fortran tests
	README the README file you've already found ;-)
	LICENSE contains license information
	runtest.pl the frame program of the test suite
	testlist-f.txt test list containing the available tests for Fortran
	testlist-c.txt test list containing the available tests for c


	------------------------------------------------------------------------------

	II. USAGE
	==============================================================================


	II.1. First run with make
	--------------------------


	You can do a first simple run of the testsuite only after one step of
	configuration:

	1) Modify the ompts.conf and ompts-c.conf file, change the number of threads
	and number of repetitions of each test.

	2) Modify the Makefile, uncommenting the CC/FC and CFLAGS/FFLAGS variables for
	the compiler of your choice.

	And now you can run the testsuite either for a C compiler with:

	> make ctest

	or for a Fortran compiler with:

	> make ftest


	II.2. Running custom tests
	--------------------------


	In order to run single tests or custom groups of tests, two make commmands
	are defined: make stest and make fstest. These two command reference the file
	customtest.txt when looking for a testlist to use. Simply edit customtest.txt
	to include the desired test or tests. If customtest.txt contains c tests,

	> make stest

	or for fortran tests

	> make fstest

	In order to change the number of threads used in the tests, simply edit the
	Makefile variables MINTHREADS and MAXTHREADS. By default, they are configured
	to use 2 threads. To change the number of times each test is run, for c tests
	edit the REPETITIONS variable in the file ompts-c.conf. The LOOPCOUNT and
	SLEEPTIME variables can also be changed here. For fortran tests, edit the file
	omp_testsuite.f to change both the LOOPCOUNT and the number of times each test
	is run.



	II.3. Understanding the results
	---------------------------------


	When running the testsuite the results will be shown on the screen.

	If you need the results for further purpose you can use the results.txt, which
	is a simple list containing the results for each directive
	in a single line. Each line starts with the name of the directive. Then follows
	the result of the test given in the percentage of the passed tests. If 100% of
	the tests passed successfully, the second number gives the result of the
	corresponding crosstest. Crosstests will only be run if the normal test passes
	with 100% accuracy. If a crosstest was not run or a test does not exist, it is
	denotated by a "-".
	After the results of the normal tests, there follow a series of tests in the
	orphaned mode. If there were no orphaned tests available this is shown by a "-".

	If you run the testsuite with different numbers of threads (e.g. using the
	runtest.pl script) the results are shown in blocks of 4 columns for each number
	of threads.

	If a test fails you can find more detailed information in the ompts.log,
	bin/c/.out and .log files. While the ompts.log file contains all compiler
	error messages for all tests, the .out and .log files contain detailed inforamtion
	on the execution process of the single tests.
	In the *.out files there are listed all the results of the single executions of
	the tests. In the *.log files there are error messages of the tests itself.


	II.4. Cleaning Up
	-----------------


	Because many files are generated for each tested directive, it is often necessary
	to clean the main directory after a battery of tests. To clean all generated files
	in the main directory including the results and log files,

	> make clean


	To clean only the logs and out files,

	> make cleanlogs

	To clean only the results,

	> make cleanresults



	II.4. Using the runtest script
	-------------------------------


	So for special purpose you can use the runtest.pl script, which allows a lot
	more options for the execution process than the execution with make.

	Using the runtest.pl script is rather easy. You can use the the test suite only
	after two steps of modifications:

	1.) Modify the Makefile to your wishes choosing your compiler and the necessary
	compiler flags.
	2.) If necessary edit one of the test lists (testlist-c.txt) and comment out the
	tests you do not want to run using # at the beginning of a line. Testlists for Fortran end
	with -f.txt while test lists for c with -c.txt.

	And now you can run the test suite either for Fortran using
	# > ./runtest.pl -lang=fortran -d=fortran testlist-f.txt
	or for c
	# > ./runtest.pl -lang=c -d=c testlist-c.txt

	With the --help option you can show the complete list of options and their
	explanations.

	The test results are summarized in cresults or fresults.txt while *.log keep
	details for individual tests. There is also a file (ompts.log) keeping
	compilation information. (see section II.2 )

	If you don't want to test the directives in orphaned mode you can use the
	-norphan option. You also can use the runtest.pl script either to compile all
	tests or run compiled tests e.g. for cross compilation on other platforms. For
	this there are the options -norun and -nocompile.

	Happy testing!


	------------------------------------------------------------------------------

	III. How to add new tests / The structure of test templates
	==============================================================================

	III.1 The template structure
	------------------------------

	The test suite is based on templates so that you only have one file for test,
	crosstest and the orphaned versions of them.

	A) Description of the template structure

	The syntax of the templates is much like xml. So each test begins with
	'<ompts:test>' and ends with '</ompts:test>'.

	In between there are several other blocks holding information:

	- <ompts:testdescription> </ompts:testdescription> In between this tag you can
	give a description on what the test checks and how it works.

	- <ompts:ompversion> </ompts:version> This tag is used to specify the
	OpenMP-version which includes the tested directive.

	- <ompts:directive> </ompts:directive> Used to specify the directive how it is
	called in the programming language.

	- <ompts:dependences> </ompts:dependences> With this tag you can specify other
	omp directives which are necessary for the correct execution of your test.
	The directives have to be listed by their directive names as it is called in
	the programming language. Multiple directives are separated by ','.

	- <ompts:testcode> </ompts:testcode> In this tag stands the whole source code
	for the test / crosstest. Each test has to be written as a function. The
	syntax of the functions differs between C and Fortran: In C it has to take a
	file pointer 'FILE * logFile' and return an int. If the test has been passed
	successful it has to return a value unequal to 0. The file pointer can be used
	to write information into a log file. In Fortran the function takes no
	argument and the function name must not exceed XX characters. The return value
	has to be specified using the '<testfunctionname>' tags. It has to be 1 if the
	test succeeded and 0 if the test failed. For details see the example.

	To tell the test suite the name of your test function you have to enclose it
	into the '<ompts:testcode:functionname> </ompts:testcode:functionname>' tag.

	If there are differences between test and crosstest you can use the
	<ompts:check> </ompts:check> and <ompts:crosscheck> </ompts:crosscheck> tag.
	When generating the test the parser will use the code enclosed in
	<ompts:check> tags and cut out the code written in <ompts:crosscheck> tags. So
	you have two possibilities to write your template for test and crosstest: The
	first way you can write the complete code is to write the test in one
	<ompts:check> tag and later the crosstest in one <ompts:crosscheck> tag. The
	second way is to write both tests only by enclosing differing parts in
	corresponding tags.

	The first method should be preferred if test and crosstest differ much from
	each other. The second e.g. if you only want to change a few options like
	replacing an omp singleprivate clause by an omp private clause or to cut out
	a directive like omp flush. When you use the first way you have to take care
	of the function name! You have to declare it twice with
	<ompts:testcode:functionname>!

	- <ompts:orphan> </ompts:orphan> This tag can be used if you want to enable
	your test to check the directive in orphan regions, too. The code enclosed
	in this part will be written to a separate function which will be called
	instead. If you have variables which are used outside this region you have to
	declare them as global variables enclosed in an <ompts:orphan:vars> tag. For
	further information see the description of the <ompts:orphan:vars> tag.

	- <ompts:orphan:vars> </ompts:orphan:vars> This tag is used to specify global
	variables for an orphan region which allow the exchange of values between
	the main program and the orphaned functions. The usage differs between C and
	Fortran. In C you have to use a single declaration for each variable. You can
	either declare all variables in one single or in several different regions. You
	must not initialize the variables inside! In Fortran you have to put all
	declarations in one single tag. Because there exist no global variables as in
	C you have to use common blocks. For further information see the examples.

	III.2. Adding tests to the test lists
	--------------------------------------

	After you have created a new test you have to add them to a testlist. Simply
	add the function name in a new Line into a file.



	------------------------------------------------------------------------------


	IV. Known Issues and Workaround
	==============================================================================

	The Sun OS has a problem with the -maxdepth option on the 'make cleanall'
	command. This prevents the tests from being removed from the working directory
	and can cause problems with future tests. To remedy, edit the makefile line
	under the clean command:

	-rm [cf]test.[cf] [cf]crosstest.[cf] [cf]ctest.[cf] [cf]orphan.[cf]

	Change to:

	-rm [cf]test* [cf]crosstest* [cf]ctest* [cf]orphan*



	------------------------------------------------------------------------------

	V. Contact and Support
	==============================================================================

	Contact: http://www.cs.uh.edu/~hpctools