[Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077

[Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077

[seurer at linux dot vnet.ibm.com]

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

            Bug ID: 96198
           Summary: new test case libgomp.c/loop-21.c in r11-2077
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at linux dot vnet.ibm.com
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

g:f418bd4b92a03ee0ec0fe4cfcd896e86e11ac2cf, r11-2077 

PASS: libgomp.c/loop-21.c (test for excess errors)
. . .
Execution timeout is: 300
spawn [open ...]
FAIL: libgomp.c/loop-21.c execution test

Running it in gdb shows:

(gdb) where
#0  0x00003fffb7c0258c in __GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x00003fffb7c04778 in __GI_abort () at abort.c:90
#2  0x0000000010003548 in .main._omp_fn.4 ()
#3  0x00003fffb7e36588 in .gomp_thread_start () from
/home/seurer/gcc/install/gcc-7.4.0/lib64/libgomp.so.1
#4  0x00003fffb7dccafc in start_thread (arg=0x3fffad21f130) at
pthread_create.c:309
#5  0x00003fffb7ce6f4c in .__clone () at
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:104

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer <seurer at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Build|                            |powerpc64*-linux-gnu
               Host|                            |powerpc64*-linux-gnu
             Target|                            |powerpc64*-linux-gnu

--- Comment #1 from Bill Seurer <seurer at linux dot vnet.ibm.com> ---
Note: failed on powerpc64 both BE and LE

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-07-14

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think
--- gcc/omp-general.c.jj        2020-07-14 12:20:01.520110629 +0200
+++ gcc/omp-general.c   2020-07-14 20:54:48.104237522 +0200
@@ -726,7 +726,7 @@ omp_extract_for_data (gomp_for *for_stmt
              if (loop->m1 || loop->m2)
                {
                  gcc_assert (single_nonrect != -1);
-                 if (single_nonrect_cond_code == LT_EXPR)
+                 if (1 || single_nonrect_cond_code == LT_EXPR)
                    {
                      n1 = n1first;
                      n2 = n2first;
@@ -764,7 +764,7 @@ omp_extract_for_data (gomp_for *for_stmt
                  m1 = fold_convert (itype, m1);
                  m2 = fold_convert (itype, m2);
                  tree t2;
-                 if (single_nonrect_cond_code == LT_EXPR)
+                 if (1 || single_nonrect_cond_code == LT_EXPR)
                    t2 = fold_build2 (MINUS_EXPR, itype, m2, m1);
                  else
                    t2 = fold_build2 (MINUS_EXPR, itype, m1, m2);
should fix that, but need to go back to drawing board and see if that is how we
want to handle those cases.  That said at least for all the testcases in the
testsuite it currently computes the right number of iterations at least.

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschwinge at gcc dot gnu.org
           Keywords|                            |openmp
   Last reconfirmed|2020-07-14 00:00:00         |2020-7-15

--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> g:f418bd4b92a03ee0ec0fe4cfcd896e86e11ac2cf, r11-2077 

(No patch submission email for that one, by the way?)


(In reply to Jakub Jelinek from comment #2)
> I think
> --- gcc/omp-general.c.jj	2020-07-14 12:20:01.520110629 +0200
> +++ gcc/omp-general.c	2020-07-14 20:54:48.104237522 +0200
> [...]
> should fix that

ACK.  (But I've only tested this one testcase.)


Not sure if that's related here, but compiling with '-O2', we see:

    libgomp.c/loop-21.c: In function ‘main._omp_fn.11’:
    libgomp.c/loop-21.c:211:11: warning: ‘.count.340’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
      211 |   #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
          |           ^~~
    libgomp.c/loop-21.c: In function ‘main._omp_fn.9’:
    libgomp.c/loop-21.c:175:11: warning: ‘.count.327’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
      175 |   #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
          |           ^~~
    libgomp.c/loop-21.c: In function ‘main._omp_fn.7’:
    libgomp.c/loop-21.c:139:11: warning: ‘.count.314’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
      139 |   #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
          |           ^~~
    libgomp.c/loop-21.c: In function ‘main._omp_fn.5’:
    libgomp.c/loop-21.c:103:11: warning: ‘.count.301’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
      103 |   #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
          |           ^~~
    libgomp.c/loop-21.c: In function ‘main._omp_fn.3’:
    libgomp.c/loop-21.c:67:11: warning: ‘.count.288’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
       67 |   #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
          |           ^~~
    libgomp.c/loop-21.c: In function ‘main._omp_fn.1’:
    libgomp.c/loop-21.c:31:11: warning: ‘.count.275’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
       31 |   #pragma omp parallel for collapse(2) lastprivate (i, j, x)
reduction(+:niters)
          |           ^~~

[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:79c12969ec3e9185fdbb90d3b1699d64b1cd0901

commit r11-2138-g79c12969ec3e9185fdbb90d3b1699d64b1cd0901
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jul 15 16:34:54 2020 +0200

    openmp: Fix up loop-21.c

    I've missed
    +FAIL: libgomp.c/loop-21.c execution test
    during testing of the recent patch.  The problem is that while
    for the number of iterations computation it doesn't matter if we compute
    min_inner_iterations as (m2 * first + n2 + (adjusted step) + m1 * first +
n1) / step
    or (m2 * last + n2 + (adjusted step) + m1 * last + n1) / step provided that
    in the second case we use as factor (m1 - m2) * ostep / step rather than
    (m2 - m1) * ostep / step, for the logical to actual iterator values
computation
    it does matter and in my hand written C implementations of all the cases
(outer
    vs. inner loop with increasing vs. decreasing iterator) I'm using the same
computation
    and it worked well for all the pseudo-random iterators testing it was
doing.

    It also means min_inner_iterations is misnamed, because it is not really
    minimum number of inner iterations, whether the first or last outer
iteration
    results in the smaller or larger value of this can be (sometimes) only
    determined at runtime.
    So this patch also renames it to first_inner_iterations.

    2020-07-15  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/96198
            * omp-general.h (struct omp_for_data): Rename min_inner_iterations
            member to first_inner_iterations, adjust comment.
            * omp-general.c (omp_extract_for_data): Adjust for the above
change.
            Always use n1first and n2first to compute it, rather than depending
            on single_nonrect_cond_code.  Similarly, always compute factor
            as (m2 - m1) * outer_step / inner_step rather than sometimes m1 -
m2
            depending on single_nonrect_cond_code.
            * omp-expand.c (expand_omp_for_init_vars): Rename
min_inner_iterations
            to first_inner_iterations and min_inner_iterationsd to
            first_inner_iterationsd.