Changes

Summary

  1. [Sema] haveSameParameterTypes - replace repeated isNull() test with assertions (details)
  2. [OpenMP][Tests][NFC] Flagging OMPT tests as XFAIL for Intel compilers (details)
  3. [OpenMP][Tests][NFC] Work around ICC bug (details)
  4. [OpenMP][OMPT] thread_num determination for programs with explicit tasks (details)
Commit 3b3509b3cba272c98d2235a8664ae9625ac729f8 by llvm-dev
[Sema] haveSameParameterTypes - replace repeated isNull() test with assertions

As reported on https://pvs-studio.com/en/blog/posts/cpp/0771/ (Snippet 2) - (and mentioned on rGdc4259d5a38409) we are repeating the T1.isNull() check instead of checking T2.isNull() as well, and at this point neither should be null - so we're better off with an assertion.

Differential Revision: https://reviews.llvm.org/D107347
The file was modifiedclang/lib/Sema/SemaOverload.cpp (diff)
Commit 5918688248fa103c46da3a6ff86e7fab0e63fb45 by protze
[OpenMP][Tests][NFC] Flagging OMPT tests as XFAIL for Intel compilers

With Intel 19 compiler the teams tests fail to link while trying to link
liboffload.
The file was modifiedopenmp/runtime/test/ompt/teams/serialized.c (diff)
The file was modifiedopenmp/runtime/test/ompt/tasks/taskwait-depend.c (diff)
The file was modifiedopenmp/runtime/test/ompt/teams/parallel_team.c (diff)
The file was modifiedopenmp/runtime/test/ompt/teams/serial_teams.c (diff)
The file was modifiedopenmp/runtime/test/ompt/tasks/dependences_mutexinoutset.c (diff)
The file was modifiedopenmp/runtime/test/ompt/teams/team.c (diff)
Commit c93fb143b98ea2035c6fca95241bc5ba40faf97e by protze
[OpenMP][Tests][NFC] Work around ICC bug
Older intel compilers miss the privatization of nested loop variables for
doacross loops. Declaring the variable in the loop makes the test more
robust.
The file was modifiedopenmp/runtime/test/ompt/synchronization/ordered_dependences.c (diff)
Commit 59a994e8daeef94976841a11bc92ca3a2b6a10b3 by protze
[OpenMP][OMPT] thread_num determination for programs with explicit tasks

__ompt_get_task_info_internal is now able to determine the right value of the
“thread_num” argument during the execution of an explicit task.

During the execution of a while loop that iterates over the ancestor tasks
hierarchy, the “prev_team” variable was always set to “team” variable at the
beginning of each loop iteration.

Assume that the program contains a parallel region which encloses an explicit
task executed by the worker thread of the region. Also assume that the tool
inquires the “thread_num” of a worker thread for the implicit task that
corresponds to the region (task at “ancestor_level == 1”) and expects to
receive the value of “thread_num > 0”.
After the loop finishes, both “team” and “prev_team” variables are equal and
point to the team information of the parallel region.
The “thread_num” is set to “prev_team->t.t_master_tid”, that is equal to
“team->t.t_master_tid”. In this case, “team->t.t_master_tid” is 0, since
the master thread of the region is the initial master thread of the program.
This leads to a contradiction.

To prevent this, “prev_team” variable is set to “team” variable only at the
time when the loop that has already encountered the implicit task (“taskdata”
variable contains the information about an implicit task) continues iterating
over the implicit task’s ancestors, if any.

After the mentioned loop finishes, the “prev_team” variable might be equal to
NULL. This means that the task at requested “ancestor_level” belongs to the
innermost parallel region, so the “thread_num” will be determined by calling
the “__kmp_get_tid”.

To prove that this patch works, the test case “explicit_task_thread_num.c” is
provided.
It contains the example of the program explained earlier in the summary.

Differential Revision: https://reviews.llvm.org/D110473
The file was modifiedopenmp/runtime/src/ompt-specific.cpp (diff)
The file was addedopenmp/runtime/test/ompt/tasks/explicit_task_thread_num.c