https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80809
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
The double-free diagnostic is due to heap corruption via OOB access in
main._omp_cpyfn.2, -fsanitize=address catches this, even with OMP_NUM_THREADS=1
and 'x' given as 3.
I think there are two issues here, first is that 'data' becomes implicitly
firstprivate in the task region while it should have been shared, and second is
that omp-expand gets confused about the size of omp_data_o passed to GOMP_task:
<bb 18>:
D.2629 = D.2628 + 35;
D.2630 = (long int) D.2629;
D.2631 = D.2630 & -8;
__builtin_GOMP_task (main._omp_fn.1, &.omp_data_o.11, main._omp_cpyfn.2,
D.2631, 8, 1, 0, 0B);
where D.2628 is not initialized.
I think the issues are separate, the second one remains even with
'firstprivate(data)' on the enclosing parallel which makes it implicitly
firstprivate on the task region iiuc.
