https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Inside: omp_build_struct_sibling_lists
new_next
= omp_accumulate_sibling_list (region_type, code,
struct_map_to_clause, *grpmap,
grp_start_p, grp_end, addr_tokens,
&inner, &fragile_p,
grp->reprocess_struct, &added_tail);
This processing looks okay. But:
/* Delete groups marked for deletion above. At this point the order of the
groups may no longer correspond to the order of the underlying list,
which complicates this a little. First clear out OMP_CLAUSE_DECL for
deleted nodes... */
FOR_EACH_VEC_ELT (*groups, i, grp)
if (grp->deleted)
for (tree d = *grp->grp_start;
d != OMP_CLAUSE_CHAIN (grp->grp_end);
d = OMP_CLAUSE_CHAIN (d))
OMP_CLAUSE_DECL (d) = NULL_TREE;
Where we have the following 4 elements. Note that grp_start is identical for
[1] and [2] – where [2] is deleted = true – which causes that the CLAUSE_DECL
are NULL. Namely, 'p (*groups)[i]' for i = 0...3 gives:
$86 = (omp_mapping_group &) @0x30f7a48: {grp_start = 0x7ffff6c92070, grp_end =
0x7ffff71f96c0, mark = UNVISITED, deleted = false, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
$91 = (omp_mapping_group &) @0x30f7a70: {grp_start = 0x7ffff71f96d0, grp_end =
0x7ffff71f9678, mark = UNVISITED, deleted = false, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
$92 = (omp_mapping_group &) @0x30f7a98: {grp_start = 0x7ffff71f96d0, grp_end =
0x7ffff71f9630, mark = UNVISITED, deleted = true, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
$93 = (omp_mapping_group &) @0x30f7ac0: {grp_start = 0x7ffff71f9640, grp_end =
0x7ffff71f9708, mark = UNVISITED, deleted = false, reprocess_struct = false,
fragile = false, sibling = 0x0, next = 0x0}
Where the '*grp_start' values of [0],[1]+[2], [3] are:
map(struct:S1 [len: 3]) map(tofrom:S1.a) map(tofrom:S1.b) map(alloc:S1.p [len:
8]) map(tofrom:*S1.p [len: 400]) map(attach_detach:S1.p [bias: 0])
map(tofrom:S1.p)
map(alloc:S1.p [len: 8]) map(tofrom:*S1.p [len: 400]) map(attach_detach:S1.p
[bias: 0]) map(tofrom:S1.p)
(gdb) p debug(*(tree*)0x7ffff71f9640)
<nil>
And 'grp_end' for [0]...[4] is:
map(tofrom:S1.b) map(alloc:S1.p [len: 8]) map(tofrom:*S1.p [len: 400])
map(attach_detach:S1.p [bias: 0]) map(tofrom:S1.p)
map(tofrom:S1.a) map(tofrom:S1.b) map(alloc:S1.p [len: 8]) map(tofrom:*S1.p
[len: 400]) map(attach_detach:S1.p [bias: 0]) map(tofrom:S1.p)
map(tofrom:S1.p)
map(attach_detach:S1.p [bias: 0]) map(tofrom:S1.p)
BEFORE that deleted loop, the result is:
(gdb) p debug(*list_p)
map(struct:S1 [len: 3]) map(tofrom:S1.a) map(tofrom:S1.b) map(alloc:S1.p [len:
8]) map(tofrom:*S1.p [len: 400]) map(attach_detach:S1.p [bias: 0])
map(tofrom:S1.p)
which looks fine. Obviously, after the deleted, all entries after 'alloc:S.p'
have CLAUSE_DECL == NULL_TREE, causing the fail.
* * *
RFC:
* Why are there two 'grp' with the same *grp_start value?
* Why does it get set to 'deleted' while its clauses are actually used?
