[Bug testsuite/100748] New: [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[Bug testsuite/100748] New: [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[seurer at gcc dot gnu.org]

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

            Bug ID: 100748
           Summary: [12 regression] 30_threads/jthread/95989.cc fails
                    after r12-843
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:60a156ae53e976dfe44689f7c89e607596e7cf67, r12-843
make  -k check RUNTESTFLAGS="conformance.exp=30_threads/jthread/95989.cc"
FAIL: 30_threads/jthread/95989.cc execution test
# of expected passes            1
# of unexpected failures        1

It looks like this fails on power 7 BE since it was reactivated.  Looks OK on
LE and power 8 BE. 

commit 60a156ae53e976dfe44689f7c89e607596e7cf67
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon May 17 14:55:22 2021 +0100

    libstdc++: Fix std::jthread assertion and re-enable skipped test


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xg++
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
-std=gnu++2a -pthread -static -fdiagnostics-plain-output ./libtestc++.a
-Wl,--gc-sections
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./95989.exe^M
PASS: 30_threads/jthread/95989.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/32::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/32::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]^M
terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error 4398050832512
FAIL: 30_threads/jthread/95989.cc execution test

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-05-24
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And apparently even on x86_64-pc-linux-gnu, though I don't see it:
https://gcc.gnu.org/pipermail/libstdc++/2021-May/052592.html

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I do see it failing on at least one powerpc64 LE machine.  PR97944 said it used
to fail randomly.

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'd better disable it again until I have time to figure it out.

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Bernd E. analyzed this in the thread referenced in c#1.

The test links staticly and we're pulling in the weak definition of
pthread_join.

I'm not sure why we're linking statically.  Reverting to normal dynamic linking
would likely fix this problem.

If that's not desired, then something like --whole-archive -lpthread
--no-whole-archive in the link line will make this work as long as it appears
before -lc.

Or we could add -Wl,-u,pthread_join to the link line.

Or we could hack up the source per Bernd's patch in that thread.

No strong opinions here.  Just trying to get another failure resolved on our
target :-)

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
PR 95989 is specifically about static linking.

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Jon -- you might want to sync with the glibc folks.  IIUC they're rolled
libpthread into libc in glibc-2.34 which may make this is a non-issue going
forward, which I can certainly live with.

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes but the point of the test (and the change it is meant to be testing) is to
verify it works before those changes.

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think it's exactly those changes which have caused this FAIL. See PR
libstdc++/103133 (which I have a patch for, and which fixes this).

Is everybody seeing this FAIL using glibc 2.34?

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:80fe172ba9820199c2bbce5d0611ffca27823049

commit r12-5108-g80fe172ba9820199c2bbce5d0611ffca27823049
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 9 23:45:36 2021 +0000

    libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

    Since Glibc 2.34 all pthreads symbols are defined directly in libc not
    libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
    avoid unnecessary locking in single-threaded programs. This means there
    is no reason to avoid linking to libpthread now, and so no reason to use
    weak symbols defined in gthr-posix.h for all the pthread_xxx functions.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100748
            PR libstdc++/103133
            * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
            Define for glibc 2.34 and later.

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This should be fixed now. Please reopen if not.

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:293075002a7eaf1e9d457a1839bcaf83f8626824

commit r11-9301-g293075002a7eaf1e9d457a1839bcaf83f8626824
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 9 23:45:36 2021 +0000

    libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

    Since Glibc 2.34 all pthreads symbols are defined directly in libc not
    libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
    avoid unnecessary locking in single-threaded programs. This means there
    is no reason to avoid linking to libpthread now, and so no reason to use
    weak symbols defined in gthr-posix.h for all the pthread_xxx functions.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100748
            PR libstdc++/103133
            * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
            Define for glibc 2.34 and later.

    (cherry picked from commit 80fe172ba9820199c2bbce5d0611ffca27823049)

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:18eecb8c4a97716d4bc4890b05c91f172fadc7b3

commit r10-10928-g18eecb8c4a97716d4bc4890b05c91f172fadc7b3
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 9 23:45:36 2021 +0000

    libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]

    Since Glibc 2.34 all pthreads symbols are defined directly in libc not
    libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
    avoid unnecessary locking in single-threaded programs. This means there
    is no reason to avoid linking to libpthread now, and so no reason to use
    weak symbols defined in gthr-posix.h for all the pthread_xxx functions.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100748
            PR libstdc++/103133
            * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK):
            Define for glibc 2.34 and later.

    (cherry picked from commit 80fe172ba9820199c2bbce5d0611ffca27823049)

[Bug testsuite/100748] [12 regression] 30_threads/jthread/95989.cc fails after r12-843

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 11.3 and 10.5 too.