Re: [Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]

2021-03-11 Thread Jerry DeLisle
Looks good Tobias, OK, Odd about that line in set_internal_unit. Probably leftover from a copy/paste. I see in comment #5 of the PR that you mentioned trying the assert to make sure it is useless code. Thanks for the patch, Jerry On 3/11/21 2:38 AM, Tobias Burnus wrote: Revised version –

[Patch] Fortran: Fix func decl mismatch [PR93660]

2021-03-11 Thread Tobias Burnus
This fixes an ICE with OpenMP 'omp decare simd' but is a generic bug. Namely TREE_TYPE(fndecl) has a mismatch to the arglist chain, missing some hidden arguments with -fcoarray=lib. OK for mainline and GCC 10? Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201,

[Patch] Fortran/OpenMP: Fix use_device_{ptr,addr} with assumed-size array [PR98858]

2021-03-11 Thread Tobias Burnus
The ICE occurs because the 't' == NULL for assumed-size arrays. For them, the size is not known – but as this should only occur for use_device_{addr,ptr}, the size is not needed. OK for mainline? Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München

Re: [Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]

2021-03-11 Thread Martin Stein via Fortran
I have seen the lock inversion with helgrind as well. Otherwise I have not seen anything more in my real code. I will give the thread sanitizer another try. Problem with both are the huge number of false positives in conjunction with typical openmp code (e.g. master thread allocates a big vector

Re: [Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]

2021-03-11 Thread Tobias Burnus
Revised version – the previous had a lock inversion, which could lead to a deadlock, found by -fsanitize=thread. See transfer.c for the changes. OK? Tobias On 11.03.21 10:42, Tobias Burnus wrote: Hi all, as found by Martin (thanks!) there is a race for newunit_free. While that call is

[Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]

2021-03-11 Thread Tobias Burnus
Hi all, as found by Martin (thanks!) there is a race for newunit_free. While that call is within the unitlock for the calls in io/unit.c, the call in transfer.c did not use locks. Additionally, unit = get_gfc_unit (dtp->common.unit, do_create); set_internal_unit (dtp, unit, kind);