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
0x13cea <+187>: movq %rbx, %rdx
-> 0x13ced <+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 ; else goto ;
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
