6 Commits
Author SHA1 Message Date
Jonathan Peyton 07f4283e71 Remove REQUIRES OMP spec version within lit tests
This is a follow up patch to D64534 (r365963) which removed all OMP
spec versioning within the OpenMP runtime codebase.  This patch removes
REQUIRES: openmp-x.y lines from lit tests.


git-svn-id: https://llvm.org/svn/llvm-project/openmp/trunk@366341 91177308-0d34-0410-b5e6-96231b3b80d8
2019-07-17 15:41:00 +00:00
Dimitry Andric cf0276b9ab Ensure correct pthread flags and libraries are used
On most platforms, certain compiler and linker flags have to be passed
when using pthreads, otherwise linking against libomp.so might fail with
undefined references to several pthread functions.

Use CMake's `find_package(Threads)` to determine these for standalone
builds, or take them (and optionally modify them) from the top-level
LLVM cmake files.

Also, On FreeBSD, ensure that libomp.so is linked against libm.so,
similar to NetBSD.

Adjust test cases with hardcoded `-lpthread` flag to use the common
build flags, which should now have the required pthread flags.

Reviewers: emaste, jlpeyton, krytarowski, mgorny, protze.joachim, Hahnfeld

Reviewed By: Hahnfeld

Subscribers: AndreyChurbanov, tra, EricWF, Hahnfeld, jfb, jdoerfert, openmp-commits

Tags: #openmp

Differential Revision: https://reviews.llvm.org/D59451


git-svn-id: https://llvm.org/svn/llvm-project/openmp/trunk@357618 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-03 18:11:36 +00:00
Roman Lebedev 600918d9e3 [OpenMP] Fixes for LIBOMP_OMP_VERSION=45/40
Summary:
I have discovered this because i wanted to experiment with
building static libomp (with openmp-4.0 support only)
for debugging purposes.

There are three kinds of problems here:
1. `__kmp_compare_and_store_acq()` simply does not exist.
   It was added in D47903 by @jlpeyton.
   I'm guessing `__kmp_atomic_compare_store_acq()` was meant.
2. In `__kmp_is_ticket_lock_initialized()`,
   `lck->lk.initialized` is `std::atomic<bool>`,
   while `lck` is `kmp_ticket_lock_t *`.
   Naturally, they can't be equality-compared.
   Either, it should return the value read from `lck->lk.initialized`,
   or do what `__kmp_is_queuing_lock_initialized()` does,
   compare the passed pointer with the field in the struct
   pointed by the pointer. I think the latter is correct-er choice here.
3. Tests were not versioned.
   They assume that `LIBOMP_OMP_VERSION` is at the latest version.

This does not touch LIBOMP_OMP_VERSION=30. That is still broken.

Reviewers: jlpeyton, Hahnfeld, AndreyChurbanov

Reviewed By: AndreyChurbanov

Subscribers: guansong, jfb, openmp-commits, jlpeyton

Tags: #openmp

Differential Revision: https://reviews.llvm.org/D55496

git-svn-id: https://llvm.org/svn/llvm-project/openmp/trunk@349260 91177308-0d34-0410-b5e6-96231b3b80d8
2018-12-15 09:23:39 +00:00
Jonas Hahnfeld b00226fdf5 Correct wrong comment in bug_nested_proxy_task.c
The nested proxy task does not have dependencies.

git-svn-id: https://llvm.org/svn/llvm-project/openmp/trunk@293472 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-30 09:51:02 +00:00
Jonas Hahnfeld b5f8854970 Mark tests with task dependencies as unsupported with GCC
git-svn-id: https://llvm.org/svn/llvm-project/openmp/trunk@277996 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-08 11:52:49 +00:00
Jonas Hahnfeld d9ae211c7d __kmp_free_task: Fix for serial explicit tasks producing proxy tasks
Consider the following code which may be executed by a serial team:

    int dep;
    #pragma omp target nowait depend(out: dep)
    {
        sleep(1);
    }
    #pragma omp task depend(in: dep)
    {
        #pragma omp target nowait
        {
            sleep(1);
        }
    }

Here the explicit task may not be freed until the nested proxy task has
finished. The current code hasn't considered this and called __kmp_free_task
anyway which triggered an assert because of remaining incomplete children:

    KMP_DEBUG_ASSERT( TCR_4(taskdata->td_incomplete_child_tasks) == 0 );

Differential Revision: https://reviews.llvm.org/D23115

git-svn-id: https://llvm.org/svn/llvm-project/openmp/trunk@277991 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-08 10:08:07 +00:00