https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #4 from martin <mscfd at gmx dot net> --- Ok, here is another suspicious data race in unit.c (backtrace from helgrind): ==7831== Possible data race during read of size 4 at 0x5DE4620 by thread #296 ==7831== Locks held: 1, at address 0x2EE5D00 ==7831== at 0x10067CB: get_gfc_unit (unit.c:336) ==7831== by 0x10071DB: _gfortrani_get_unit (unit.c:556) ==7831== by 0x10050DC: data_transfer_init (transfer.c:2851) ... ==7831== ==7831== This conflicts with a previous write of size 4 by thread #3 ==7831== Locks held: 1, at address 0x5DE4700 ==7831== at 0x10069F4: _gfortrani_set_internal_unit (unit.c:459) ==7831== by 0x10071EC: _gfortrani_get_unit (unit.c:557) ==7831== by 0x10050DC: data_transfer_init (transfer.c:2851) There seems to be a conflicting access to "unit_cache[c]->unit_number", set_internal_unit does not hold UNIT_LOCK. I cannot observe this in the simple testcase, but in the real code at the right place where I suspect the write-caused memory corruption. (Just in case line numbers have changed: unit.c:336: if (unit_cache[c] != NULL && unit_cache[c]->unit_number == n) unit.c:556: iunit->unit_number = dtp->common.unit; )
