[clang][OpenMP] Fix build when using libgomp

[rupprecht]

Summary

rL356570 introduced a test which only passes with the default openmp library, libomp, and fails with other openmp libraries, such as libgomp. Explicitly choose libomp.

[lebedev.ri]

Interesting.
What happens if libomp is not being built?
What happens if libomp is not present?

Or more generally, why does it even matter whether there is runtime or not, this only does paring+sema, no codegen/execution.

[ABataev]

If the compiler is built without OpenMP support -fopenmp is converted to -fopenmp=libgomp frontend option.

[ABataev]

LG

[rupprecht]

In D59609#1436975, @lebedev.ri wrote:

Interesting.
What happens if libomp is not being built?
What happens if libomp is not present?

I'm far from an omp expert (only running across this because some tests failed), but I would guess both those cases to break.

But this is broken anyway when libomp isn't being used. So the set of broken cases is going from (people that don't use libomp) to (people that don't have libomp) which I think is a much smaller subset.

Or more generally, why does it even matter whether there is runtime or not, this only does paring+sema, no codegen/execution.

I'm very surprised myself. Hence my question "has something gone wrong" on D59214. Hopefully this fix/hack can be reverted once that's figured out.

unittests/AST/OMPStructuredBlockTest.cpp

 }
 
 template <typename T>
 ::testing::AssertionResult
 PrintedOMPStmtMatches(StringRef Code, const T &NodeMatch,
                       StringRef ExpectedPrinted,
                       PolicyAdjusterType PolicyAdjuster = None) {
   std::vector<std::string> Args = {
-      "-fopenmp",
+      "-fopenmp=libomp",
   };
   return PrintedStmtMatches(Code, Args, NodeMatch, ExpectedPrinted,
                             PolicyAdjuster);
 }
 
 static testing::AssertionResult NoMatches(StringRef Code,
                                           const StatementMatcher &StmtMatch) {
   PrintMatch Printer((PolicyAdjusterType()));