https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #6 from Gareth Davies ---
(In reply to anlauf from comment #4)
> There is one flaw with the testcase: when OMP_NUM_THREADS > n1,
> array elements threadval(n1+1:OMP_NUM_THREADS) are filled with
> undefined values.
Yes, my bad in try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #5 from Andrew Pinski ---
Maybe instead of:
!$omp parallel
nt = omp_get_num_threads()
!$omp end parallel
Do:
nt = omp_get_max_threads()
that should improve the situtation of not allocating enough for the array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #4 from anlauf at gcc dot gnu.org ---
There is one flaw with the testcase: when OMP_NUM_THREADS > n1,
array elements threadval(n1+1:OMP_NUM_THREADS) are filled with
undefined values.
When I replace the line
if(omp_get_thread_num(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108336
--- Comment #3 from Andrew Pinski ---
Yes the race condition is the following:
the order of calling random_number on which thread first.
init_rand_state definitely takes a lock when reading/writing from/to
master_state.
I see no other race con
