[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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?