[Bug libgomp/80809] Multi-free error for variable size array used within OpenMP task

2017-05-18 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80809

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
I'll handle this.

[Bug libgomp/80809] Multi-free error for variable size array used within OpenMP task

2017-05-18 Thread amonakov at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80809

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
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:

  :
  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.