[Bug libstdc++/108235] New: FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[Bug libstdc++/108235] New: FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

            Bug ID: 108235
           Summary: FAIL: g++.dg/compat/abi/bitfield1
                    cp_compat_x_tst.o-cp_compat_y_tst.o link
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
              Host: hppa64-hp-hpux11.11
            Target: hppa64-hp-hpux11.11
             Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../ cp_compat_main_tst.o
cp_com
pat_x_tst.o cp_compat_y_tst.o -fdiagnostics-plain-output -nostdinc++
-I/home/dav
e/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/d
ave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/inc
lude/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-fmessage-len
gth=0 -w -ansi -pedantic-errors -funsigned-bitfields
-L/home/dave/gnu/gcc/objdir
64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir64/hp
pa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/./libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hp
ux11.11/./libstdc++-v3/src/experimental/.libs -lm -o
g++-dg-compat-abi-bitfield1
-01.exe
ld: (Warning) Unsatisfied symbol "__atomic_fetch_add_4" in file
/home/dave/gnu/g
cc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl
ld: (Warning) Unsatisfied symbol "__atomic_fetch_add_8" in file
/home/dave/gnu/g
cc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl
ld: (Warning) Unsatisfied symbol "__atomic_compare_exchange_4" in file
/home/dav
e/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl
ld: (Warning) Unsatisfied symbol "__atomic_compare_exchange_8" in file
/home/dav
e/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl
ld: (Warning) Unsatisfied symbol "__atomic_fetch_sub_8" in file
/home/dave/gnu/g
cc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl
ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in file
/home/dave/gnu/gc
c/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl
6 warnings.
FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

I believe libstdc++ needs to be linked against libatomic to provide these
symbols.

This might affect also affect linux target.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot com

--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> ---
bash-5.1$ find . -name '*.o'|xargs /opt/gnu64/bin/nm -AC|grep atomic
./src/c++98/pool_allocator.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/mt_allocator.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/ios_failure.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/ios_init.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/locale_init.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/locale.o:                 U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++98/localename.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/stdexcept.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/messages_members_cow.o:                 U
__gnu_cxx::__atomic_add(int volatile*, int)
./src/c++11/cow-stdexcept.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/ios-inst.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-locale_init.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-shim_facets.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cxx11-shim_facets.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-string-inst.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-wstring-inst.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++17/fs_dir.o:                 U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++17/fs_ops.o:                 U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++17/cow-fs_dir.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++17/cow-fs_ops.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++17/cow-fs_path.o:                 U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++20/tzdb.o:                 U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++20/tzdb.o:0000000000000000 t void
std::__atomic_notify_address<int>(int const*, bool) [clone .isra.0]
./src/c++20/tzdb.o:0000000000000000 W void std::__atomic_wait_address_v<int,
std::__atomic_base<int>::wait(int, std::memory_order) const::{lambda()#1}>(int
const*, int, std::__atomic_base<int>::wait(int, std::memory_order)
const::{lambda()#1})
./src/c++20/tzdb.o:                 U __atomic_compare_exchange_4
./src/c++20/tzdb.o:                 U __atomic_compare_exchange_8
./src/c++20/tzdb.o:                 U __atomic_exchange_8
./src/c++20/tzdb.o:                 U __atomic_fetch_add_4
./src/c++20/tzdb.o:                 U __atomic_fetch_add_8
./src/c++20/tzdb.o:                 U __atomic_fetch_sub_8
[...]

I believe the direct use of the above atomic symbols was introduced in the
following change:

commit 9fc61d45fa15fdd3b084d30998ecda164af33e95
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Dec 22 00:37:54 2022 +0000

    libstdc++: Implement C++20 time zone support in <chrono>

I have the following patch to work around PR 108228:

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 2a4e213d3d9..92752242096 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -64,8 +64,8 @@ namespace __gnu_cxx
 #else
   [[gnu::weak]] const char* zoneinfo_dir_override();

-#ifdef __APPLE__
-  // Need a weak definition for Mach-O.
+#if defined(__APPLE__) || defined(__hpux__)
+  // Need a weak definition for Mach-O and HP-UX.
   [[gnu::weak]] const char* zoneinfo_dir_override()
   { return _GLIBCXX_ZONEINFO_DIR; }
 #endif

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin <danglin at gcc dot gnu.org> ---
Looks like ./libstdc++-v3/config/cpu/hppa/atomicity.h needs updating to provide
undefined routines.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 54168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54168&action=edit
Preprocessed source for tzdb.cc

See atomic routines needed by tzdb.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-12-30
             Status|UNCONFIRMED                 |ASSIGNED

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin <danglin at gcc dot gnu.org> ---
Working on a patch to add support for sync libfuncs.

Downside is one needs to add -fno-sync-libcalls to generate calls for
libatomic.  I think the HP implementations of pthread_mutex_lock and
pthread_mutex_unlock in libpthread are better than what I will do for
the sync routines.  That's why I haven't implemented the sync routines
before.

Is there an alternative?

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
tzdb.cc doesn't need atomics, it can just work with a mutex. I'm still on
holiday until tomorrow though.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 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:b1ad748754401613b5cf8e5d46b38ad1ee49d07a

commit r13-5003-gb1ad748754401613b5cf8e5d46b38ad1ee49d07a
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Jan 4 16:45:14 2023 +0000

    libstdc++: Only use std::atomic<tzdb_list::_Node*> if lock free [PR108228]

    This fixes linker errors for hppa-hp-hpux11.11 due to an undefined weak
    symbol and the use of atomic operations that require libatomic.

    The weak symbol can simply be defined, which we already do for darwin.

    The std::atomic<_Node*> is only an optimization, so can be avoided for
    targets where the underlying atomic ops aren't available without help
    from libatomic. The accesses to the std::atomic<_Node*> can be
    abstracted behind a new API for getting and setting the cached value,
    and then the atomics can be used conditionally.

    libstdc++-v3/ChangeLog:

            PR libstdc++/108228
            PR libstdc++/108235
            * config/abi/pre/gnu.ver: Move zoneinfo_dir_override export to
            the latest symbol version.
            * src/c++20/tzdb.cc (USE_ATOMIC_SHARED_PTR): Define to 0 if
            atomic<_Node*> is not always lock free.
            (USE_ATOMIC_LIST_HEAD): New macro.
            [__hpux__] (__gnu_cxx::zoneinfo_dir_override()): Provide
            definition of weak symbol.
            (tzdb_list::_Node::_S_head): Rename to _S_head_cache.
            (tzdb_list::_Node::_S_list_head): New function for accessing
            list head efficiently.
            (tzdb_list::_Node::_S_cache_list_head): New function for
            updating _S_list_head.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Does that fix it?

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2023-01-04 7:54 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235
>
> --- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> Does that fix it?
I just started a new build and check.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

--- Comment #9 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 54206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54206&action=edit
Updated preprocessed source

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin <danglin at gcc dot gnu.org> ---
No.  We still have the following symbols in tzdb.o:
                 U __atomic_compare_exchange_4
                 U __atomic_fetch_add_4
                 U __atomic_fetch_add_8
                 U __atomic_fetch_sub_8

There was this warning compiling tzdb.o:
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In function 'std::string
std::chrono::{anonymous}::zoneinfo_dir()':
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:983:44: warning: the address
of 'const char* __gnu_cxx::zoneinfo_dir_override()' will never be NULL
[-Waddress]
  983 |       static const string dir = __gnu_cxx::zoneinfo_dir_override
      |                                 ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:77:29: note: 'const char*
__gnu_cxx::zoneinfo_dir_override()' declared here
   77 |   [[gnu::weak]] const char* zoneinfo_dir_override()
      |                             ^~~~~~~~~~~~~~~~~~~~~

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John David Anglin from comment #10)
> No.  We still have the following symbols in tzdb.o:
>                  U __atomic_compare_exchange_4
>                  U __atomic_fetch_add_4

Oh the time_zone::_Impl::rules_counter atomic counter is still used even if not
lock-free. I can fix that.

>                  U __atomic_fetch_add_8
>                  U __atomic_fetch_sub_8

Ah, these are caused by __detail::__platform_wait_t being uint64_t, which will
be changed soon by
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609479.html
That would mean we only need 4-byte atomics, but if I stop using
time_zone::_Impl::rules_counter for this target, we won't need that either.

> 
> There was this warning compiling tzdb.o:
> ../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc: In function 'std::string
> std::chrono::{anonymous}::zoneinfo_dir()':
> ../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:983:44: warning: the
> address of 'const char* __gnu_cxx::zoneinfo_dir_override()' will never be
> NULL [-Waddress]
>   983 |       static const string dir = __gnu_cxx::zoneinfo_dir_override
>       |                                 ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
> ../../../../../gcc/libstdc++-v3/src/c++20/tzdb.cc:77:29: note: 'const char*
> __gnu_cxx::zoneinfo_dir_override()' declared here
>    77 |   [[gnu::weak]] const char* zoneinfo_dir_override()
>       |                             ^~~~~~~~~~~~~~~~~~~~~

Harmless, it's just because we added the definition of that weak symbol, so now
it's never null.

I'll add a #pragma to ignore -Waddress there.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 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:61da01772a3dff61cf23ba2ffba33bccb68d1063

commit r13-5052-g61da01772a3dff61cf23ba2ffba33bccb68d1063
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Jan 6 18:39:14 2023 +0000

    libstdc++: Refactor time_zone::_Impl::rules_counter [PR108235]

    Abstract the atomic counter used to synchronize access to time_zone
    infos behind a Lockable class API, and use atomic_signed_lock_free
    instead of atomic<int_least32_t>, as that should be the most efficient
    type. (For futex-supporting targets it makes no difference, but might
    benefit other targets in future.)

    The new API allows the calling code to be simpler, without needing to
    repeat the same error prone preprocessor conditions in multiple places.
    It also allows using template metaprogramming to decide whether to use
    the atomic or a mutex, which gives us more flexibility than only using
    preprocessor conditions. That allows us to choose the mutex
    implementation for targets such as hppa-hp-hpux11.11 where 32-bit
    atomics are not lock-free and so would introduce an unwanted dependency
    on libatomic.

    libstdc++-v3/ChangeLog:

            PR libstdc++/108235
            * src/c++20/tzdb.cc (time_zone::_Impl::RulesCounter): New class
            template and partial specialization for synchronizing access to
            time_zone::_Impl::infos.
            (time_zone::_M_get_sys_info, reload_tzdb): Adjust uses of
            rules_counter.

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe this time!

[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

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

--- Comment #14 from John David Anglin <danglin at gcc dot gnu.org> ---
Yes.