Hi!
I've noticed this test fails intermittently.
The problem is that it wasn't correct, without the in_reduction
clause this patch adds (or e.g. without #pragma omp atomic) there
is a data race, multiple tasks can update concurrently the same variable.
Tested on x86_64-linux, previously it would fail every 10-100 runs here,
now it doesn't fail in 10000 of them.
Committed to trunk.
2018-11-08 Jakub Jelinek <ja...@redhat.com>
* testsuite/libgomp.c-c++-common/task-reduction-8.c (bar): Add
in_reduction clause for s[0].
--- libgomp/testsuite/libgomp.c-c++-common/task-reduction-8.c.jj
2018-11-08 18:08:04.178942068 +0100
+++ libgomp/testsuite/libgomp.c-c++-common/task-reduction-8.c 2018-11-08
20:31:32.824942285 +0100
@@ -45,7 +45,8 @@ unsigned long long int
bar (int z, int *a, unsigned long long int *b, int *s)
{
unsigned long long int x = 1;
- #pragma omp taskloop reduction (*:x) in_reduction (*:b[0])
+ #pragma omp taskloop reduction (*:x) in_reduction (*:b[0]) \
+ in_reduction (+:s[0])
for (int i = z; i < z + 8; i++)
{
#pragma omp task in_reduction (*:x)
Jakub
