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

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

[tom.vanderaa at gmail dot com]

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

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Pedantically, your testcase has UB and therefore anything can happen, because
aa variable is uninitialized and it is being incremented.
But it crashes even after fixing that (= {}), so I'll have a look.

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[tom.vanderaa at gmail dot com]

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

--- Comment #2 from Tom Vander Aa <tom.vanderaa at gmail dot com> ---
Thanks Jakub. Let me know when I can do something.

-Wno-pedantic,
Tom

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
   Last reconfirmed|                            |2021-05-10

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The bug isn't specific to UDRs, but about the taskloop having zero iterations,
GOMP_taskloop in the library performing an early return as there is no work to
do (but it would do similar thing if containing parallel got cancelled), which
means
      if (flags & GOMP_TASK_FLAG_REDUCTION)
        {
          struct gomp_data_head { TYPE t1, t2; uintptr_t *ptr; };
          uintptr_t *ptr = ((struct gomp_data_head *) data)->ptr;
          ialias_call (GOMP_taskgroup_reduction_register) (ptr);
        }
wasn't performed.  But in the code emitted in the caller of GOMP_taskloop GCC
relies on that being done.

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50785&action=edit
gcc12-pr100471.patch

Untested fix.

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[tom.vanderaa at gmail dot com]

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

--- Comment #5 from Tom Vander Aa <tom.vanderaa at gmail dot com> ---

This seems also to fix the original code, which I used to derive the test case.
(patch applied on master)

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a

commit r12-706-g98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 11 09:07:47 2021 +0200

    openmp: Fix up taskloop reduction ICE if taskloop has no iterations
[PR100471]

    When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early
    return, doesn't create any tasks and more importantly, doesn't create
    a taskgroup and doesn't register task reductions.  But, the code emitted
    in the callers assumes task reductions have been registered and performs
    the reduction handling and task reduction unregistration.  The pointer
    to the task reduction private variables is reused, on input it is the
alignment
    and only on output it is the pointer, so in the case taskloop with no
iterations
    the caller attempts to dereference the alignment value as if it was a
pointer
    and crashes.  We could in the early returns register the task reductions
    only to have them looped over and unregistered in the caller, but I think
    it is better to tell the caller there is nothing to task reduce and bypass
    all that.

    2021-05-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100471
            * omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data
            is 0, bypass the reduction loop including
            GOMP_taskgroup_reduction_unregister call.

            * taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not
            GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task
            reduction pointer.
            * testsuite/libgomp.c/task-reduction-4.c: New test.

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:58ce04708738840fa1917c49f686ce0266ba6e77

commit r11-8402-g58ce04708738840fa1917c49f686ce0266ba6e77
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 11 09:07:47 2021 +0200

    openmp: Fix up taskloop reduction ICE if taskloop has no iterations
[PR100471]

    When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early
    return, doesn't create any tasks and more importantly, doesn't create
    a taskgroup and doesn't register task reductions.  But, the code emitted
    in the callers assumes task reductions have been registered and performs
    the reduction handling and task reduction unregistration.  The pointer
    to the task reduction private variables is reused, on input it is the
alignment
    and only on output it is the pointer, so in the case taskloop with no
iterations
    the caller attempts to dereference the alignment value as if it was a
pointer
    and crashes.  We could in the early returns register the task reductions
    only to have them looped over and unregistered in the caller, but I think
    it is better to tell the caller there is nothing to task reduce and bypass
    all that.

    2021-05-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100471
            * omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data
            is 0, bypass the reduction loop including
            GOMP_taskgroup_reduction_unregister call.

            * taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not
            GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task
            reduction pointer.
            * testsuite/libgomp.c/task-reduction-4.c: New test.

    (cherry picked from commit 98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a)

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.2/12+ so far.
Should be backported to 9 and 10 which do support task reductions.

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:49bfa539e240cd769179751f18c472f9a4ea2248

commit r10-10608-g49bfa539e240cd769179751f18c472f9a4ea2248
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 11 09:07:47 2021 +0200

    openmp: Fix up taskloop reduction ICE if taskloop has no iterations
[PR100471]

    When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early
    return, doesn't create any tasks and more importantly, doesn't create
    a taskgroup and doesn't register task reductions.  But, the code emitted
    in the callers assumes task reductions have been registered and performs
    the reduction handling and task reduction unregistration.  The pointer
    to the task reduction private variables is reused, on input it is the
alignment
    and only on output it is the pointer, so in the case taskloop with no
iterations
    the caller attempts to dereference the alignment value as if it was a
pointer
    and crashes.  We could in the early returns register the task reductions
    only to have them looped over and unregistered in the caller, but I think
    it is better to tell the caller there is nothing to task reduce and bypass
    all that.

    2021-05-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100471
            * omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data
            is 0, bypass the reduction loop including
            GOMP_taskgroup_reduction_unregister call.

            * taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not
            GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task
            reduction pointer.
            * testsuite/libgomp.c/task-reduction-4.c: New test.

    (cherry picked from commit 98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a)

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:c0844e105880b98e943812770088f51fc37211e6

commit r9-10070-gc0844e105880b98e943812770088f51fc37211e6
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue May 11 09:07:47 2021 +0200

    openmp: Fix up taskloop reduction ICE if taskloop has no iterations
[PR100471]

    When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early
    return, doesn't create any tasks and more importantly, doesn't create
    a taskgroup and doesn't register task reductions.  But, the code emitted
    in the callers assumes task reductions have been registered and performs
    the reduction handling and task reduction unregistration.  The pointer
    to the task reduction private variables is reused, on input it is the
alignment
    and only on output it is the pointer, so in the case taskloop with no
iterations
    the caller attempts to dereference the alignment value as if it was a
pointer
    and crashes.  We could in the early returns register the task reductions
    only to have them looped over and unregistered in the caller, but I think
    it is better to tell the caller there is nothing to task reduce and bypass
    all that.

    2021-05-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/100471
            * omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data
            is 0, bypass the reduction loop including
            GOMP_taskgroup_reduction_unregister call.

            * taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not
            GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task
            reduction pointer.
            * testsuite/libgomp.c/task-reduction-4.c: New test.

    (cherry picked from commit 98acbb3111fcb5e57d5e63d46c0d92f4e53e3c2a)

[Bug middle-end/100471] #pragma omp taskloop with custom reduction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.