Build fails for openmp #159
Labels
build-problem
cmake
Build system in general and CMake in particular
openmp
question
A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!
Comments
|
Stale cmake files? They should be setting C++ 14 as of a couple of weeks ago edit: though I can't find where we set the c++ version for the plugins (not currently at a desk) so it maybe we're just using the default, which is 11 and won't work any more. If so you can work around by specifying c++14 |
|
I see that patch - 3ff4e2e And I am still able to build openmp if I checkout the commit before this patch. |
|
I have tried passing c++14 as option to cmake. It didn't work
I get the same error. |
|
Finally I can reproduced it now, but I didn’t find anything wrong in the dry run: As you can see |
|
I have root cause the issue, if you append Still using head files from system which is 4.8.5. GCC 4.8.5 has partially support for C++14 so that’s why that function is not found. |
|
And how to set this option in cmake? |
|
Try |
|
This worked. Thanks Shilei for the help. |
|
I still don't understand one thing. Why does clang use system provided gcc, even if we specified our own compiler with the CMAKE_CXX_COMPILER option? |
|
That is different stories. |
RKSimon
added
cmake
|
@llvm/issue-subscribers-openmp |
EugeneZelenko
added
the
question
mjklemm
pushed a commit
to mjklemm/llvm-project
that referenced
this issue
Oct 1, 2024
…duction clauses to generate info. (llvm#159) * Move teams reductions from distribute to teams and use the reduction clause for the teams directive to create the reduction information. * Remove composite matching framework since this is no longer needed with the new teams reduction implementation.
jpinot
pushed a commit
to jpinot/llvm-project
that referenced
this issue
Apr 9, 2025
Here is a description of the implementation. Clang: Taskiter (for) is modeled as a loop directive, like taskloop. Taskiter (while) is more permissive, allowing any C/C++ condition in the while loop. This includes lambdas and condition using pointers. The loop iterator is firstprivate instead of private. Because in the llvm transform is needed. - Unroll clause is an integer > 0 NOTE: At this time the loop iterator is not usable in taskiter (for) clauses. NOTE: At this time while condition used variables are not specially handled to make them shared variables NOTE: There is no support for stride() clause yet. Its implementation is the same as unroll clause LLVM: Taskiter is lowered in the unpack function as a simple body without the loop. In particular, taskiter (for) includes the body and emits the code to increment the iterator. In taskiter (while) only the body is emitted. The reason is because the runtime will have the amount of iterations to execute (for version), or a task_info field with the function that evaluates the condition. NOTE: In contrast to Clang, Taskiter is NOT a loop directive because the lowering in the unpack function differs. Special rebase notes: Remove apparently unused code to clear OSSLateParsedToks In 35ff500 removing this code results in the test error. I add the test to keep track we do not introduce the bug again. Reference llvm#159
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When trying to build openmp I'm getting the following error:
I never faced this issue till a couple of weeks back.
I always build my llvm with clang first and then use the clang to build openmp with offloading support.
To build llvm/clang:
To build openmp:
My gcc version is 6.5.0
The text was updated successfully, but these errors were encountered: