(no subject)

[mscfd]

> 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 a newunits array 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 into character variable is done. Now "newunit_alloc" uses a lock to avoid having several thread all over the place. But newunit_free also writes to newunits array. And this routine does not obtain a lock itself (see comment 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 much).
 
Any thoughts?
Martin

Re:

[Richard Biener]

On Wed, Mar 10, 2021 at 8:39 PM mscfd via Fortran <fortran@gcc.gnu.org> wrote:
>
> > 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 a newunits array 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 into character variable is done. Now "newunit_alloc" uses a lock to avoid having several thread all over the place. But newunit_free also writes to newunits array. And this routine does not obtain a lock itself (see comment 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 much).
>
> Any thoughts?

try obtaining the locks around the places you figured and see if your
problem goes away?

> Martin