Fix broken OpenMP runtime test cases for Windows

[protze.joachim]

Summary

Three test cases used Pthreads.
I added a new feature pthread to specify REQUIRES: pthread
This feature currently is derived from the OS property (Linux). Are these tests expected to work on Darwin? I could not find a CMake variable for Pthreads in a quick survey.

The other broken test is that for Windows omp_control_tool is not exported in the dll.

[Hahnfeld]

Are these tests expected to work on Darwin?

I didn't see them failing and it's a POSIX system, so I'd say this should work.

[Hahnfeld]

https://github.com/llvm-mirror/openmp/blob/master/runtime/cmake/config-ix.cmake#L131

# Checking Threading requirements
find_package(Threads REQUIRED)
if(WIN32)
  if(NOT CMAKE_USE_WIN32_THREADS_INIT)
    libomp_error_say("Need Win32 thread interface on Windows.")
  endif()
else()
  if(NOT CMAKE_USE_PTHREADS_INIT)
    libomp_error_say("Need pthread interface on Unix-like systems.")
  endif()
endif()

So we can assume to have pthreads on all systems except Windows.

[protze.joachim]

Assuming we have pthread on all platforms but Windows

[Hahnfeld]

@hans Does this work for you?

[hans]

In D42427#985319, @Hahnfeld wrote:

@hans Does this work for you?

I'm on my way out from the office. I'll try to test it tomorrow. Thanks!

runtime/src/dllexports

542

This one seems unrelated?

[Hahnfeld]

runtime/src/dllexports

542

No, it's need because all symbols not listed here are hidden when linking the OpenMP runtime library and will result in errors when compiling the test that uses the symbol.

[protze.joachim]

runtime/src/dllexports

542

This one is the reason why the test/ompt/misc/control_tool_no_ompt_support.c test case failed.
With OpenMP 5.0 this function is part of the interface. Even if the runtime is built without OMPT support, this function needs to be provided as a stub, returning a meaningful value.

I think, these lines should add the function to the exported symbols of the OpenMP dll.

If you build with LIBOMP_OMP_VERSION < 50, the test might still fail, because of the issue I fixed in D42432

[hans]

This works for me if the NEEDS are replaced with REQUIRES.

ompt/misc/control_tool_no_ompt_support.c still fails though:

FAIL: libomp :: ompt/misc/control_tool_no_ompt_support.c (66 of 161)
******************** TEST 'libomp :: ompt/misc/control_tool_no_ompt_support.c' FAILED ********************
Script:
--
C:/src/llvm/build.release/./bin/clang.exe -fopenmp  -I C:/src/llvm/projects/openmp/runtime/test -I C:/src/llvm/build.release/projects/openmp/runtime/src -L C:/src/llvm/build.release/bin  C:\src\llvm\projects\openmp\runtime\test\ompt\misc\control_tool_no_ompt_support.c -o C:\src\llvm\build.release\projects\openmp\runtime\test\ompt\misc\Output\control_tool_no_ompt_support.c.tmp && C:\src\llvm\build.release\projects\openmp\runtime\test\ompt\misc\Output\control_tool_no_ompt_support.c.tmp
--
Exit Code: 1120

Command Output (stdout):
--
$ "C:/src/llvm/build.release/./bin/clang.exe" "-fopenmp" "-I" "C:/src/llvm/projects/openmp/runtime/test" "-I" "C:/src/llvm/build.release/projects/openmp/runtime/src" "-L" "C:/src/llvm/build.release/bin" "C:\src\llvm\projects\openmp\runtime\test\ompt\misc\control_tool_no_ompt_support.c" "-o" "C:\src\llvm\build.release\projects\openmp\runtime\test\ompt\misc\Output\control_tool_no_ompt_support.c.tmp"
# command output:
control_tool_no_ompt_support-faece2.o : error LNK2019: unresolved external symbol omp_control_tool referenced in function .omp_outlined.
C:\src\llvm\build.release\projects\openmp\runtime\test\ompt\misc\Output\control_tool_no_ompt_support.c.tmp : fatal error LNK1120: 1 unresolved externals

# command stderr:
clang.exe: error: linker command failed with exit code 1120 (use -v to see invocation)

error: command failed with exit status: 1120

--

runtime/test/misc_bugs/omp_foreign_thread_team_reuse.c

2

NEEDS should be REQUIRES

[protze.joachim]

@omalyshe do you have any advice, what is needed to make the omp_control_tool symbol available on Windows?

My naive approach was to follow the things done for omp_get_thread_num.

[omalyshe]

In D42427#987692, @protze.joachim wrote:

@omalyshe do you have any advice, what is needed to make the omp_control_tool symbol available on Windows?

My naive approach was to follow the things done for omp_get_thread_num.

Adding omp_control_tool to dllexports is a right way.

LGTM.

[protze.joachim]

In D42427#987710, @omalyshe wrote:

In D42427#987692, @protze.joachim wrote:

@omalyshe do you have any advice, what is needed to make the omp_control_tool symbol available on Windows?

My naive approach was to follow the things done for omp_get_thread_num.

Adding omp_control_tool to dllexports is a right way.

LGTM.

The problem is, that according to Hans' tests, the symbol is still not available in the runtime. The test (https://github.com/llvm-mirror/openmp/blob/master/runtime/test/ompt/misc/control_tool_no_ompt_support.c) litterally only calls this single function. But the linker complains about the missing symbol.

[omalyshe]

In D42427#987666, @hans wrote:

This works for me if the NEEDS are replaced with REQUIRES.

ompt/misc/control_tool_no_ompt_support.c still fails though:

Did you replace NEEDS with REQUIRES in this test as well? (REQUIRES: omp50)

[hans]

In D42427#987732, @omalyshe wrote:

In D42427#987666, @hans wrote:

This works for me if the NEEDS are replaced with REQUIRES.

ompt/misc/control_tool_no_ompt_support.c still fails though:

Did you replace NEEDS with REQUIRES in this test as well? (REQUIRES: omp50)

There was no NEEDS line in that file. Does omp50 get defined anywhere? Grepping the OpenMP repository for it yields no matches.

[omalyshe]

There was no NEEDS line in that file. Does omp50 get defined anywhere? Grepping the OpenMP repository for it yields no matches.

It was defined in https://reviews.llvm.org/D42432

[protze.joachim]

It was defined in https://reviews.llvm.org/D42432

Will be added ...

The question for your failure: What is your setting for LIBOMP_OMP_VERSION?

[protze.joachim]

NEEDS replaced by REQUIRES

[hans]

In D42427#987844, @protze.joachim wrote:

It was defined in https://reviews.llvm.org/D42432

Will be added ...

The question for your failure: What is your setting for LIBOMP_OMP_VERSION?

I have no idea.

I'm just checking out openmp under projects/, configuring with "cmake -GNinja -DCMAKE_BUILD_TYPE=Release" and trying to build check-all.

I don't know anything about OpenMP on Windows, I just build the releases.

As it seems there is nobody regularly testing and maintaining the Windows support, I've taken it out of the release builds.

[omalyshe]

FAIL: libomp :: ompt/misc/control_tool_no_ompt_support.c (66 of 161)

• TEST 'libomp :: ompt/misc/control_tool_no_ompt_support.c' FAILED ****

Script:

C:/src/llvm/build.release/./bin/clang.exe -fopenmp -I C:/src/llvm/projects/openmp/runtime/test -I C:/src/llvm/build.release/projects/openmp/runtime/src -L C:/src/llvm/build.release/bin C:\src\llvm\projects\openmp\runtime\test\ompt\misc\control_tool_no_ompt_support.c -o C:\src\llvm\build.release\projects\openmp\runtime\test\ompt\misc\Output\control_tool_no_ompt_support.c.tmp && C:\src\llvm\build.release\projects\openmp\runtime\test\ompt\misc\Output\control_tool_no_ompt_support.c.tmp

Does Clang on Windows accept -L option? I doubt.

To find new symbols like omp_control_tool at compile time the path to the corresponding libomp.lib should be specified either by adding it to LIB environment variable or by putting the libomp.lib with the full path to the compiler command line:
$ clang -fopenmp -I <path to omp.h> <path to libomp.lib>\libomp.lib <source file>

To link with the libomp.dll in run-time set PATH to where libomp.dll is located.

runtime/src/dllexports

%ifdef stub
         omp_target_memcpy_rect              887
         omp_target_associate_ptr            888
         omp_target_disassociate_ptr         889
     %endif
 %endif # OMP_45
 
 kmp_set_disp_num_buffers                    890
 
+%ifdef OMP_50
+    omp_control_tool                        891
+%endif # OMP_50
+
 %ifndef stub
     # Ordinals between 900 and 999 are reserved
 
     # Ordinals between 1000 and 1999 are reserved
     # for user-callable uppercase Fortran entries.
 
 
     # ATOMIC entries

runtime/test/lit.cfg

 if config.has_ompt:
     config.available_features.add("ompt")
     # for callback.h
     config.test_flags += " -I " + config.test_source_root + "/ompt"
 
 if 'Linux' in config.operating_system:
     config.available_features.add("linux")
 
+if config.operating_system != 'Windows':
+    config.available_features.add("pthread")
+
 # to run with icc INTEL_LICENSE_FILE must be set
 if 'INTEL_LICENSE_FILE' in os.environ:
     config.environment['INTEL_LICENSE_FILE'] = os.environ['INTEL_LICENSE_FILE']
 
 
 # substitutions
 config.substitutions.append(("%libomp-compile-and-run", \
     "%libomp-compile && %libomp-run"))

runtime/test/misc_bugs/omp_foreign_thread_team_reuse.c

 // RUN: %libomp-compile -lpthread && %libomp-run
+// REQUIRES: pthread
+
 #include <stdio.h>
 #include "omp_testsuite.h"
 
 #define NUM_THREADS 10
 
 /*
  After hot teams were enabled by default, the library started using levels
  kept in the team structure.  The levels are broken in case foreign thread

runtime/test/tasking/bug_nested_proxy_task.c

 // RUN: %libomp-compile -lpthread && %libomp-run
 // The runtime currently does not get dependency information from GCC.
 // UNSUPPORTED: gcc
+// REQUIRES: pthread
 
 #include <stdio.h>
 #include <omp.h>
 #include <pthread.h>
 #include "omp_my_sleep.h"
 
 /*
  With task dependencies one can generate proxy tasks from an explicit task

runtime/test/tasking/bug_proxy_task_dep_waiting.c

 // RUN: %libomp-compile -lpthread && %libomp-run
 // The runtime currently does not get dependency information from GCC.
 // UNSUPPORTED: gcc
+// REQUIRES: pthread
 
 #include <stdio.h>
 #include <omp.h>
 #include <pthread.h>
 #include "omp_my_sleep.h"
 
 /*
  An explicit task can have a dependency on a target task. If it is not