https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is well defined.
Anyway, most likely the bug is already during gimplification.
I see in the omplower dump:
int[0:(sizetype) D.2477] & c;
...
D.2477 = D.2476 + -1;
...
#pragma omp target num_teams(1) thread_limit(0) map(from:err [len: 4])
firstprivate(d) firstprivate(t) firstprivate(v) firstprivate(y) priv
ate(i) private(c) private(s) private(u) private(x) [child fn:
_Z3fooRiS_R1SS1_RdS2_._omp_fn.0 (.omp_data_arr.7, .omp_data_sizes.8,
.omp_data_kinds.
9)]
{
try
{
...
D.2689 = (sizetype) D.2477;
D.2690 = D.2689 + 1;
D.2691 = D.2690 * 4;
D.2692 = __builtin_alloca_with_align (D.2691, 32);
c = D.2692;
Accessing an automatic variable from the caller inside of target region is
wrong, it should have been made firstprivate during gimplification, which would
allow it to work.
