Fix classification of some microkernels

[jprotze]

The two renamed benchmarks do not contain a data race.
DRB142 did not contain a data race. Removing the critical, adds back the intended data race.

[thelechen]

Hi @jprotze,

Thank you for the PR. For micro-benchmarks/DRB129-mergeable-taskwait-orig-no.c, What if the code is the following? Does it contain data races? Thank you!

#include <omp.h>
#include <stdio.h>
void func(int *x)
{
#pragma omp task mergeable
    {
        (*x)++;
    }
#pragma omp taskwait
}

int main()
{
    int x = 2;
#pragma omp parallel
    {
        func(&x);
    }
    printf("%d\n", x);
    return 0;
}

[thelechen]

Hi @jprotze
Regarding micro-benchmarks/DRB142-acquirerelease-orig-yes.c, we think the original intention is to have thread 1 read variable x. Would changing y to x at line 41 correct the code and introduce the data race? Thank you!

[jprotze]

Hi @jprotze Regarding micro-benchmarks/DRB142-acquirerelease-orig-yes.c, we think the original intention is to have thread 1 read variable x. Would changing y to x at line 41 correct the code and introduce the data race? Thank you!

The comment describes a different intent. The implicit flush for the atomic signalling on y does not introduce flush-synchronization for reading x. The problem of the initial code is that the critical region guarding the read of x in the if-statement does actually add the flush-synchronization. Removing the critical avoids this flush-synchronization and implements the issue described in the header of the file.

[jprotze]

Your change suggested for DRB129 changes the test to a completely different test than documented in the comment. I think, the idea of the test is good. It is just not a data race.