Patch by Victor Campos

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

llvm-svn: 288056

Cleanup: memory leaks on warnings printing fixed; some memory freeing cleaned; poor indents and one typo fixed.

Patch by Victor Campos.

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

llvm-svn: 288054

llvm-svn: 287552

Paul Osmialowski pointed out a double free bug in shutdown code.  This patch
Moves the freeing of the implicit task to above the freeing of all fast memory
to prevent the double-free issue.

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

llvm-svn: 287551

Have developer timers use partitioning scheme which also required that some
redundant developer timers be removed in favor of the already existing normal
timers. Move per thread stats initialization to just after global thread id
assignment which is as early as possible. Also put all global stats
initialization code in __kmp_stats_init() and all global stats destruction code
in __kmp_stats_fini().

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

llvm-svn: 286892

This set of changes enables the affinity interface (Either the preexisting
native operating system or HWLOC) to be dynamically set at runtime
initialization. The point of this change is that we were seeing performance
degradations when using HWLOC. This allows the user to use the old affinity
mechanisms which on large machines (>64 cores) makes a large difference in
initialization time.

These changes mostly move affinity code under a small class hierarchy:

KMPAffinity
  class Mask {}
KMPNativeAffinity : public KMPAffinity
  class Mask : public KMPAffinity::Mask
KMPHwlocAffinity
  class Mask : public KMPAffinity::Mask

Since all interface functions (for both affinity and the mask implementation)
are virtual, the implementation can be chosen at runtime initialization.

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

llvm-svn: 286890

Patch by Victor Campos.

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

llvm-svn: 286441

This patch allows ThreadSanitizer (Tsan) to verify OpenMP programs.
It means that no false positive will be reported by Tsan when
verifying an OpenMP programs.
This patch introduces annotations within the OpenMP runtime module to
provide information about thread synchronization to the Tsan runtime.

In order to enable the Tsan support when building the runtime, you must
enable the TSAN_SUPPORT option with the following environment variable:

-DLIBOMP_TSAN_SUPPORT=TRUE

The annotations will be enabled in the main shared library
(same mechanism of OMPT).

Patch by Simone Atzeni and Joachim Protze!

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

llvm-svn: 286115

llvm-svn: 285947

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

llvm-svn: 285833

Check Task Scheduling Constraint (TSC) on stealing of untied task.
This is needed because the untied task can produce tied children
those can break TSC if untied is not a descendant of current task.
This can cause live lock on complex tyasking tests
(e.g. kastors/strassen-task-dep).

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

llvm-svn: 285703

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

Patch by Victor Campos

llvm-svn: 285678

Differential Revision: http://reviews.llvm.org/D25504

Patch by Alex Duran.

llvm-svn: 285283

Patch by Victor Campos

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

llvm-svn: 285244

Patch by Victor Campos

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

llvm-svn: 285243

Differential Revision: http://reviews.llvm.org/D25510

llvm-svn: 284747

Summary:
If directives are used in a macro, clang complains with:
```
src/projects/openmp/runtime/src/kmp_runtime.c:7486:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]
#if KMP_USE_MONITOR
```

This patch fixes two occurrences of the issue in `kmp_runtime.cpp`.

Reviewers: tlwilmar, jlpeyton, AndreyChurbanov, Hahnfeld

Subscribers: Hahnfeld, openmp-commits

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

llvm-svn: 284728

Patch by Andrey Churbanov

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

llvm-svn: 284499

Function strerror_r() has different signatures in different
implementations of libc: glibc's version returns a char*, while BSDs
and musl return a int. libomp unconditionally assumes glibc on Linux
and thus fails to compile against musl-libc. This patch addresses this
issue.

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

llvm-svn: 284492

New mixed type atomic routines added for regular capture operations as well as
reverse update/capture operations.  LHS - all integer and float types (no
complex so far), RHS - float16.

Patch by Olga Malysheva

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

llvm-svn: 284489

This change removes/disables unnecessary code when monitor thread is not used.

Patch by Hansang Bae

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

llvm-svn: 283577

As the code is now, calling omp_get_schedule() when OMP_SCHEDULE=static_steal
will cause an assert.

llvm-svn: 283576

If affinity is not capable, then these API functions will perform the stubs
version.

llvm-svn: 282947

Add check for "45" version to use "201511" string for OpenMP 4.5,
otherwise "200505" is used in Fortran module. Also, fix kmp_openmp_version
variable (used for the debugger, e.g.) and kmp_version_omp_api that is used
in KMP_VERSION=1 output.

Patch by Olga Malysheva

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

llvm-svn: 282868

New routines should be used for atomics like "<int>OP=<float>" when <int> is
unsigned. Using functions __kmpc_atomic_fixed<bits>_<op>_fp) produces incorrect
results

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

llvm-svn: 282509

This change set disables creation of the monitor thread by default.  The global
counter maintained by the monitor thread was replaced by logic that uses system
time directly, and cyclic yielding on Linux target was also removed since there
was no clear benefit of using it. Turning on KMP_USE_MONITOR variable (=1)
enables creation of monitor thread again if it is really necessary for some
reasons.

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

llvm-svn: 282507

Introduce a new LIBOMP_INSTALL_VARIABLES cache variable that can be used
to disable creating libgomp and libiomp5 aliases on 'make install'.
Those aliases are undesired e.g. on Gentoo systems where libomp is used
purely by clang.

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

llvm-svn: 281512

Previous differencials D23305-D23310 changed task frame information management only for the kmp interface, but not for the whole gomp interface. This broke some testcases when building with gcc.
This patch fixes the broken task frame information for the gomp interface.

Patch by Joachim Protze!

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

llvm-svn: 281468

In case, the current team is a serialized team (lwt), the frame information should be written to this data structure.
Before, nested serialized teams would overwrite the same task information.

Patch by Joachim Protze!

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

llvm-svn: 281467

The comment already states, that this function should work similarly as __ompt_get_taskinfo.

The function only looked for lwt entries of the current team, but not when unrolling the parents. This fix aligns the implementation to __ompt_get_taskinfo.

The new test case creates a single theaded team (->lwt) and then a nested active team.
Before the innermost print_id(1) would deliver a different team then the outer print_id(0).

Patch by Joachim Protze!

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

llvm-svn: 281466

The exit address is set when execution of a task is started and should be reset as soon as the execution is finished.
Especially for the asm implementation of __kmp_invoke_microtask, resetting in this call would be painfull, so reset just after the invokation.

The testcase shows the effect of this patch:
Before, the implicit barriers at the end of an implicit task would see an exit address for the implicit task.

This barrier is a task scheduling point. Thus, any explicit task scheduled there would see an exit, but no reenter address for the implicit task.

Patch by Joachim Protze!

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

llvm-svn: 281465

The latest OMPT spec changed the semantic of a tasks reenter frame to be the application frame, that will be entered, when the runtime frame drops.
Before it was the last frame in the runtime. This doesn't work for some gcc execution pathes or even clang generated code for :
Since there is no runtime frame between the executed task and the encountering task.

The test case compares exit and reenter addresses against addresses captured in application code

Patch by Joachim Protze!

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

llvm-svn: 281464

Rather than checking KMP_CPU_SETSIZE, which doesn't exist when using Hwloc, we
use the get_max_proc() function which can vary based on the operating system.
For example on Windows with multiple processor groups, it might be the case that
the highest bit possible in the bitmask is not equal to the number of hardware
threads on the machine but something higher than that.

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

llvm-svn: 281245

Implementation of missing OpenMP 4.0 API functions omp_get_default_device and omp_set_default_device.
Also, added support for the environment variable OMP_DEFAULT_DEVICE.

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

llvm-svn: 281065

When affinity isn't supported, __kmp_affinity_compact doesn't exist.  The
problem is that in kmp_affinity.h there is a function which uses it without the
proper KMP_AFFINITY_SUPPORTED guard around it.  The compiler was smart enough to
ignore it and the function __kmp_affinity_cmp_Address_child_num which relies on
it, but I think it is cleaner to have it under the proper guard.  Since the
function is only used in the kmp_affinity.cpp file and there aren't any plans to
have it elsewhere.  I have moved it there.

llvm-svn: 280542

the __kmp_affinity_determine_capable() functions are highly operating system
specific.  This change has the functions use the type they expect explicitly.

llvm-svn: 280538

llvm-svn: 280530

In case atomic reduction method is not available (the compiler can't generate
it) the assertion failure occurred if KMP_FORCE_REDUCTION=atomic was specified.
This change replaces the assertion with a warning and sets the reduction method
to the default one - 'critical'.

Patch by Olga Malysheva

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

llvm-svn: 280519

cleanup: fixed names of dummy arguments of Fortran interfaces declarations, no functional changes done

llvm-svn: 278951

Differential Revision: http://reviews.llvm.org/D23175

llvm-svn: 278332