https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121453
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
In omp_extract_for_data, the variables are created – but actually not assigned
to.
That happens later in expand_omp_for_init_counts and expand_oacc_for, which
touches the 'count' variable (alias loop.n2) as:
assign_stmt = gimple_build_assign (fd->loop.n2, ...
or
expexpand_omp_build_assign (gsi, fd->loop.n2, t);
Obviously, this does not happen in all cases - as shown by this PR.
The condition is created as
cond = build2 (cond_code, boolean_type_node, fd->loop.v, n2);
in lower_omp_for_lastprivate, which is called via
case GIMPLE_OMP_FOR:
...
lower_omp_for (gsi_p, ctx);
[where we have:
if (gimple_omp_for_kind (fd.for_stmt) == GF_OMP_FOR_KIND_SIMD) ]
And for SIMD, we have a 'lastprivate':
#pragma omp simd lastprivate(i) lastprivate(j) lastprivate(k) collapse(3)
Whereas 'expand_omp_for_init_counts' is called inside
expand_omp_for_generic
expand_omp_for_static_chunk
expand_omp_for_static_nochunk
expand_omp_simd
expand_omp_taskloop_for_outer
expand_omp_taskloop_for_inner
The expand_omp_simd contains:
bool broken_loop = region->cont == NULL;
...
if (fd->collapse > 1
&& (gimple_omp_for_combined_into_p (fd->for_stmt)
|| broken_loop))
{
...
expand_omp_for_init_counts (fd, &gsi, entry_bb, counts,
zero_iter_bb, first_zero_iter,
dummy_bb, dummy, l2_dom_bb);
Seems as if the condition causes a problem: As it is 'false', the 'count' and
'iter' variables are never set - but it is still used in the condition:
if (.iter.33 == .count.34)
