]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/testsuite/ChangeLog-2014-2021
[gdb/testsuite] Stabilize execution order in omp-par-scope.c
authorTom de Vries <tdevries@suse.de>
Mon, 20 Jul 2020 12:40:52 +0000 (14:40 +0200)
committerTom de Vries <tdevries@suse.de>
Mon, 20 Jul 2020 12:40:52 +0000 (14:40 +0200)
commitb243ba58e833dbb03f3746c0146f1450822c5d05
tree404f612c9bac73fb5430b45acec7cb34a93b7812
parent98b3697bcdedb92739d8feb9b881efdd70fd40d3
[gdb/testsuite] Stabilize execution order in omp-par-scope.c

In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent
on omp_get_thread_num ().  Since execution order of the threads can vary from
execution to execution, this can cause changes in test results.

F.i., we can see this difference between two test runs:
...
-KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214)
+PASS: single_scope: first thread: print i3
-PASS: single_scope: second thread: print i3
+KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214)
...
In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case
that corresponds to the first thread executing that bit of code, and in the
other case to the second thread.

Get rid of this difference by stabilizing execution order.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-20  Tom de Vries  <tdevries@suse.de>

* gdb.threads/omp-par-scope.c (lock, lock2): New variable.
(omp_set_lock_in_order): New function.
(single_scope, multi_scope, nested_func, nested_parallel): Use
omp_set_lock_in_order and omp_unset_lock.
(main): Init and destroy lock and lock2.
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.threads/omp-par-scope.c