https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66820
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, the problem is that the fold_stmt folding added in that revision creates
new decls that it doesn't put into the current gimplification context vars, but
instead creates whole function temporaries.
So we have in *.gimple:
#pragma omp parallel num_threads(num_nthreads) shared(filenames)
{
char * D.2570;
long unsigned int D.2571;
{
char filename[508];
int i;
try
{
i = 0;
D.2570 = filenames[i];
strcpy (&filename, D.2570);
D.2571 = __builtin_strlen (&filename);
D.2572 = &filename + D.2571;
__builtin_memcpy (D.2572, "[data]", 7);
}
finally
{
filename = {CLOBBER};
}
}
where the D.2572 temporary has been created by fold_stmt, but it hasn't been
added into the parallel region (nor has private(D.2572) clause which would work
too).
Right now in gimplify.c maybe_fold_stmt has a hack to avoid folding anything
inside of ORT_TARGET regions, perhaps we should extend that also to
(ctx->region_type & (ORT_PARALLEL | ORT_TASK)) != 0 too (and adjust lower_omp
to fold_stmt accordingly even when taskreg_nesting_level is non-zero).
Or get rid of fold_stmt during gimplification altogether, though that is
supposedly not suitable for gcc 5 (and keep doing it only in forwprop and
later)?
