[Bug middle-end/100471] New: #pragma omp taskloop with

[tom.vanderaa at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100471

            Bug ID: 100471
           Summary: #pragma omp taskloop with
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tom.vanderaa at gmail dot com
  Target Milestone: ---

Created attachment 50774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50774&action=edit
Preprocessed source code

Code in attach contains a #pragma omp taskloop with a custom reduction
operator.

#pragma omp taskloop default(none) shared(c) reduction(ArrayPlus: aa)

It seems that the code generated for the #pragma omp is incorrect, as the code
segfaults at

    0x100003cea <+187>: movq   %rbx, %rdx
->  0x100003ced <+190>: movzbl 0x28(%rdx), %eax

with the #pragma line above as source ref in my debugger.

Looing at taskloop_customreduce.c.007t.omplower output I'm GUESSING(!!) this
corresponds to this line (marked --->):

                #pragma omp taskloop _reductemp_(D.2068) _looptemp_(D.2067)
_looptemp_(D.2066) firstprivate(D.2062) reduction(aa) default(none) private(j)
[child fn: taskloop_reduce._omp_fn.0 (.omp_data_o.2)]
                  {
                    .omp_data_i = (struct  & restrict) &.omp_data_o.2;
                    D.2074 = .omp_data_i->D.2073;
                    D.2076 = .omp_data_i->D.2075;
                    D.2078 = .omp_data_i->D.2077;
                    D.2080 = .omp_data_i->D.2079;
                    D.2099 = __builtin_omp_get_thread_num ();
                    D.2100 = (sizetype) D.2099;
                    D.2101 = D.2100 * 64;
                    D.2102 = MEM[(unsigned long *)D.2074 + 16B];
                    D.2103 = (void *) D.2102;
                    D.2104 = D.2103 + D.2101;
                    D.2105 = D.2104;
                    D.2106 = D.2105 + 40;
  ----->            D.2107 = *D.2106;
                    if (D.2107 != 0) goto <D.2109>; else goto <D.2108>;

Tracing back this load through the gimple tree does not seem to lead to correct
struct. 

Compile command:

gcc -v -save-temps -fdump-tree-all -O0 -g -fopenmp  -o taskloop_customreduce
taskloop_customreduce.c

Tested with gcc 10.2.0 on macOS.
Tested with 9.3.0, 10.3.0 and 11.1.0 on Linux