https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #6 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566596.html
@Martin: Besides helgrind, you could also try building your program with
-fsanitize=thread - this might also help finding some issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #5 from Tobias Burnus ---
(In reply to martin from comment #4)
> Ok, here is another suspicious data race in unit.c (backtrace from helgrind):
It looks as if - for the libgfortran internal use - it first gets the unit
based on that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #4 from martin ---
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==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #3 from martin ---
Thanks for looking at the report and providing a patch to test.
For completeness sake, here is the simple test code, which does not fail, but
which shows the data race in helgrind (compile with -fopenmp -g2):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #2 from Richard Biener ---
Or make an internal (static) newunit_free_unlocked and make the exported
newunit_free take the lock.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #1 from Tobias Burnus ---
Regarding calling newunit_alloc, that's due to libgfortran/io/unit.c's:
get_unit (st_parameter_dt *dtp, int do_create)
{
gfc_unit *unit;
if ((dtp->common.flags & IOPARM_DT_HAS_INTERNAL_UNIT) != 0)
