You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replacing the memoize version of Fibonacci in benchmarks/RacyFibonacci.cc with a bruteforce version, I get dozens of false positive reports for the race-free version:
longcomp_fib_numbers(int n) {
if ( n == 0 || n == 1 ) return n;
long a=0, b=0; // line 19
#pragma omp task firstprivate(n) shared(a) // line 21
{
a = comp_fib_numbers(n - 1); // line 23
}
#pragma omp task firstprivate(n) shared(b) // line 26
{
b = comp_fib_numbers(n - 2); // line 28
}
#pragma omp taskwait // comment for racy versionlong fn = a+b; // line 32// #pragma omp taskwait // uncomment for racy versionreturn fn;
}
19 (19) <--> 23 (23) on 12 memory addresses
19 (19) <--> 28 (28) on 11 memory addresses
19 (19) <--> 32 (32) on 24 memory addresses
21 (21) <--> 21 (21) on 10 memory addresses
21 (21) <--> 23 (23) on 13 memory addresses
21 (21) <--> 26 (26) on 15 memory addresses
21 (21) <--> 28 (28) on 15 memory addresses
23 (23) <--> 23 (23) on 9 memory addresses
23 (23) <--> 26 (26) on 15 memory addresses
23 (23) <--> 32 (32) on 14 memory addresses
26 (26) <--> 26 (26) on 7 memory addresses
26 (26) <--> 28 (28) on 13 memory addresses
28 (28) <--> 28 (28) on 11 memory addresses
28 (28) <--> 32 (32) on 14 memory addresses
My suspicion is that reuse of stack addresses causes these reports. The reuse of stack addresses happens, when tasks are executed at the same call stack depth.
Is this a fundamental problem of the analysis approach, or can this be fixed?
The text was updated successfully, but these errors were encountered:
Replacing the memoize version of Fibonacci in benchmarks/RacyFibonacci.cc with a bruteforce version, I get dozens of false positive reports for the race-free version:
My suspicion is that reuse of stack addresses causes these reports. The reuse of stack addresses happens, when tasks are executed at the same call stack depth.
Is this a fundamental problem of the analysis approach, or can this be fixed?
The text was updated successfully, but these errors were encountered: