Sorry for the noise, but line breaks and subject were somehow missing... > which version of gfortran, and which operating system? I have seen this on two different Linux distros on x86 with a recently compiled version, but also some time ago with an older gfortran 10 version.
Using helgrind on a simple omp do loop with write to a character variable, I get some possible data races in libgfortran/io/unit.c. There global array newunits is allocated and possibly reallocated in "newunit_alloc". According to the lock outputs from helgrind I see that this routine is called even if output is into a character variable. Routine "newunit_alloc" uses a lock to avoid having several threads all over the place. But newunit_free also writes to newunits array. And this routine does not obtain a lock itself (see comment above newunit_free in unit.c) So in theory it can happen that newunit_alloc reallocated newunits, and newunit_free writes to it just at this time. As I also use 18 threads the initial size of 16 does not suffice and reallocation does probably indeed happen. Also acces to newunit_lwi is not protected as well (and complained about by helgrind). Could it be that the corresponding write routine in transfer.c which calls newunit_free does not obtain the necessary lock. I cannot find it (which does not count for much). Any thoughts? Martin
