[Bug libgomp/106894] New: [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[Bug libgomp/106894] New: [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[seurer at gcc dot gnu.org]

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

            Bug ID: 106894
           Summary: [13 regression] multiple libgomp failures after
                    r13-2545-g9f2fca56593a2b
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

g:9f2fca56593a2b87026b399d26adcdca90705685, r13-2545-g9f2fca56593a2b: 62
failures

FAIL: libgomp.c++/../libgomp.c-c++-common/display-affinity-1.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/icv-6.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/display-affinity-1.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/icv-6.c execution test
FAIL: libgomp.c/affinity-2.c execution test
FAIL: libgomp.fortran/affinity1.f90   -O2  execution test
FAIL: libgomp.fortran/affinity2.f90   -O2  execution test
FAIL: libgomp.fortran/display-affinity-1.f90   -O  execution test

I am not sure what the execution failures are reporting.  Here are two
examples:

spawn [open ...]^M
L:00000%0>rain6p1.aus.stglabs.ibm.com     <!     
rain6p1.aus.stglabs.ibm.com!2339838_0x200000056990_0x0000200000056990_-000001
0-7
L:00000%0>rain6p1.aus.stglabs.ibm.com     <!     
rain6p1.aus.stglabs.ibm.com!2339838_0x200000056990_0x0000200000056990_-000001
0-7
%000000001
FAIL: libgomp.c++/../libgomp.c-c++-common/display-affinity-1.c execution test


spawn [open ...]^M
 omp_get_num_places () ==            3
 place            0  {           6           7 }
 place            1  {           4           5 }
 place            2  {           0           1 }
 place            0
 partition            0 -           2

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x2000000604a7 in ???
#1  0x2000004b65ac in gomp_team_start
        at /home/seurer/gcc/git/gcc-test/libgomp/team.c:382
#2  0x2000004aa787 in GOMP_parallel
        at /home/seurer/gcc/git/gcc-test/libgomp/parallel.c:176
#3  0x100015fb in ???
#4  0x10000fa3 in ???
#5  0x200000589de7 in ???
#6  0x200000589fd3 in ???
#7  0xffffffffffffffff in ???
FAIL: libgomp.fortran/affinity1.f90   -O2  execution test



commit 9f2fca56593a2b87026b399d26adcdca90705685 (HEAD, refs/bisect/bad)
Author: Marcel Vollweiler <marcel@codesourcery.com>
Date:   Thu Sep 8 10:01:33 2022 -0700

    OpenMP, libgomp: Environment variable syntax extension

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53556&action=edit
gcc13-pr106894.patch

Lightly tested fix.

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 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:26a1f4fcb264d110708483815c8c8d7bb4ff6788

commit r13-2559-g26a1f4fcb264d110708483815c8c8d7bb4ff6788
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Sep 9 13:43:43 2022 +0200

    libgomp: Fix up OMP_PROC_BIND handling [PR106894]

    While the first param is char (gomp_global_icv.bind_var), the second param
    is char * (gomp_bind_var_list), so we shouldn't access it through *(char
*).

    2022-09-09  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/106894
            * env.c (initialize_env) <case PARSE_BIND>: Use char ** instead of
            char * for dest[1] initialization from params[1].  Formatting
fixes.

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[marcel at codesourcery dot com]

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

--- Comment #4 from Marcel Vollweiler <marcel at codesourcery dot com> ---
Thanks Jakub!

Although I checked for regressions, unfortunately I haven't seen this
regression due to the dg-set-target-env-var topic.

I assume that the icv-6.c test FAIL is caused by some other issue (your patch
fixes the issue when multiple values are defind for OMP_PROC_BIND that is not
the case in icv-6.c). 

So, I will have another look at icv-6.c ASAP.

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, sorry about icv-6.c, I did debug just one of the testcases and after fixing
it tested all the mentioned tests and all passed, so thought it is fixed.
I can now reproduce it though.
The thing is,
make check
or
make check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
in libgomp obj dir work fine, but
make -j32 -k check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
fails.
The thing is that the testcase as written relies on OMP_NUM_THREADS not being
set in environment (as it takes priority over OMP_NUM_THREADS_ALL for the
host).
So, if either a user has OMP_NUM_THREADS=42 in the environment by himself, or
when doing make check with -jN, we trigger:
          if test $$num_cpus -gt 8 && test -z "$$OMP_NUM_THREADS"; then \
            OMP_NUM_THREADS=8; export OMP_NUM_THREADS; \
            echo @@@ libgomp OMP_NUM_THREADS adjusted to 8 because of parallel
make check and too many CPUs; \
          fi; \
in libgomp/testsuite/Makefile.am and so the test fails.

So, I think we need something like:
--- libgomp/testsuite/libgomp.c-c++-common/icv-6.c.jj   2022-09-08
20:22:07.903182970 +0200
+++ libgomp/testsuite/libgomp.c-c++-common/icv-6.c      2022-09-09
16:49:29.442195701 +0200
@@ -17,6 +17,7 @@

 #include <omp.h>
 #include <stdlib.h>
+#include <string.h>

 int
 main ()
@@ -25,21 +26,28 @@ main ()
   int chunk_size;
   omp_get_schedule(&kind, &chunk_size);

-  if (omp_get_max_teams () != 42
-      || !omp_get_dynamic ()
-      || kind != 3 || chunk_size != 4
-      || omp_get_teams_thread_limit () != 44
-      || omp_get_thread_limit () != 45
-      || omp_get_max_threads () != 46
-      || omp_get_proc_bind () != omp_proc_bind_spread
-      || omp_get_max_active_levels () != 47)
+  if ((!getenv ("OMP_NUM_TEAMS") && omp_get_max_teams () != 42)
+      || (!getenv ("OMP_DYNAMIC") && !omp_get_dynamic ())
+      || (!getenv ("OMP_SCHEDULE") && (kind != 3 || chunk_size != 4))
+      || (!getenv ("OMP_TEAMS_THREAD_LIMIT") && omp_get_teams_thread_limit ()
!= 44)
+      || (!getenv ("OMP_THREAD_LIMIT") && omp_get_thread_limit () != 45)
+      || (!getenv ("OMP_NUM_THREADS") && omp_get_max_threads () != 46)
+      || (!getenv ("OMP_PROC_BIND") && omp_get_proc_bind () !=
omp_proc_bind_spread)
+      || (!getenv ("OMP_MAX_ACTIVE_LEVELS") && omp_get_max_active_levels () !=
47))
     abort ();

   int num_devices = omp_get_num_devices () > 3 ? 3 : omp_get_num_devices ();
-  for (int i=0; i < num_devices; i++)
+  for (int i = 0; i < num_devices; i++)
+    {
+      char name[sizeof ("OMP_NUM_TEAMS_DEV_0")];
+      strcpy (name, "OMP_NUM_TEAMS_DEV_0");
+      name[sizeof ("OMP_NUM_TEAMS_DEV_0") - 2] = '0' + i;
+      if (getenv (name))
+       continue;
     #pragma omp target device (i)
       if (omp_get_max_teams () != 43)
        abort ();
+    }

   return 0;
 }
or if we say users are on their own if they make check with any OMP_*
environment variables,
then at least do that for OMP_NUM_THREADS because we set it ourselves.

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:994ea892bd02dd8a1c04875ad3553c57939c3abf

commit r13-2617-g994ea892bd02dd8a1c04875ad3553c57939c3abf
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Sep 12 10:48:19 2022 +0200

    libgomp: Fix up icv-6.c [PR106894]

    The thing is,
    make check
    or
    make check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
    in libgomp obj dir work fine, but
    make -j32 -k check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'"
    fails.
    The thing is that the testcase as written relies on OMP_NUM_THREADS not
being
    set in environment (as it takes priority over OMP_NUM_THREADS_ALL for the
    host).
    So, if either a user has OMP_NUM_THREADS=42 in the environment by himself,
or
    when doing make check with -jN, we trigger:
              if test $$num_cpus -gt 8 && test -z "$$OMP_NUM_THREADS"; then \
                OMP_NUM_THREADS=8; export OMP_NUM_THREADS; \
                echo @@@ libgomp OMP_NUM_THREADS adjusted to 8 because of
parallel
    make check and too many CPUs; \
              fi; \
    in libgomp/testsuite/Makefile.am and so the test fails.

    2022-09-12  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/106894
            * testsuite/libgomp.c-c++-common/icv-6.c: Include string.h.
            (main): Avoid tests for which corresponding non-_ALL suffixed
variable
            is in the environment, or for OMP_NUM_TEAMS on the device
            OMP_NUM_TEAMS_DEV_?.

[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be now fixed completely.