Synchronize sourceware version of the libiberty sources with the master gcc versions.

Synchronize sourceware version of the libiberty sources with the master gcc versions.

This brings in the following commits:

commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Dec 5 23:32:19 2023 +0100

    libiberty: Fix build with GCC < 7

    Tobias reported on IRC that the linker fails to build with GCC 4.8.5.
    In configure I've tried to use everything actually used in the sha1.c
    x86 hw implementation, but unfortunately I forgot about implicit function
    declarations.  GCC before 7 did have <cpuid.h> header and bit_SHA define
    and __get_cpuid function defined inline, but it didn't define
    __get_cpuid_count, which compiled fine (and the configure test is
    intentionally compile time only) due to implicit function declaration,
    but then failed to link when linking the linker, because
    __get_cpuid_count wasn't defined anywhere.

    The following patch fixes that by using what autoconf uses in AC_CHECK_DECL
    to make sure the functions are declared.

commit 691858d279335eeeeed3afafdf872b1c5f8f4201
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date:   Tue Dec 5 11:04:06 2023 +0100

    libiberty: Fix pex_unix_wait return type

    The recent warning patches broke Solaris bootstrap:

    /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t,  int *, struct pex_time *, int,  const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int,  int *, struct pex_time *, int,  const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t,  int *, struct pex_time *, int,  const char **, int *)' {aka 'int (*)(struct pex_obj *, long int,  int *, struct pex_time *, int,  const char **, int *)'} [-Wincompatible-pointer-types]
      326 |   pex_unix_wait,
          |   ^~~~~~~~~~~~~
    /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait')

    While pex_funcs.wait expects a function returning pid_t, pex_unix_wait
    currently returns int.  However, on Solaris pid_t is long for 32-bit,
    but int for 64-bit.

    This patches fixes this by having pex_unix_wait return pid_t as
    expected, and like every other variant already does.

    Bootstrapped without regressions on i386-pc-solaris2.11,
    sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and
    x86_64-apple-darwin23.1.0.

commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6
Author: Jason Merrill <jason@redhat.com>
Date:   Mon Sep 25 10:15:02 2023 +0100

    c++: mangle function template constraints

    Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and
    https://github.com/itanium-cxx-abi/cxx-abi/pull/166

    We need to mangle constraints to be able to distinguish between function
    templates that only differ in constraints.  From the latter link, we want to
    use the template parameter mangling previously specified for lambdas to also
    make explicit the form of a template parameter where the argument is not a
    "natural" fit for it, such as when the parameter is constrained or deduced.

    I'm concerned about how the latter link changes the mangling for some C++98
    and C++11 patterns, so I've limited template_parm_natural_p to avoid two
    cases found by running the testsuite with -Wabi forced on:

    template <class T, T V> T f() { return V; }
    int main() { return f<int,42>(); }

    template <int i> int max() { return i; }
    template <int i, int j, int... rest> int max()
    {
      int sub = max<j, rest...>();
      return i > sub ? i : sub;
    }
    int main() {  return max<1,2,3>(); }

    A third C++11 pattern is changed by this patch:

    template <template <typename...> class TT, typename... Ts> TT<Ts...> f();
    template <typename> struct A { };
    int main() { f<A,int>(); }

    I aim to resolve these with the ABI committee before GCC 14.1.

    We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38
    (mangling references to dependent template-ids where the name is fully
    resolved) as references to concepts in std:: will consistently run into this
    area.  This is why mangle-concepts1.C only refers to concepts in the global
    namespace so far.

    The library changes are to avoid trying to mangle builtins, which fails.

    Demangler support and test coverage is not complete yet.

commit f2c52c0dfde581461959b0e2b423ad106aadf179
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date:   Thu Nov 30 10:06:23 2023 +0100

    libiberty: Disable hwcaps for sha1.o

    This patch

    commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
    Author: Jakub Jelinek <jakub@redhat.com>
    Date:   Tue Nov 28 13:14:05 2023 +0100

        libiberty: Use x86 HW optimized sha1

    broke Solaris/x86 bootstrap with the native as:

    libtool: compile:  /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go
    ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000  [ SHA1 ]
    gccgo: fatal error: Killed signal terminated program go1

    As is already done in a couple of other similar cases, this patches
    disables hwcaps support for libiberty.

    Initially, this didn't work because config/hwcaps.m4 uses target_os, but
    didn't ensure it is defined.

    Tested on i386-pc-solaris2.11 with as and gas.

commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Nov 28 13:14:05 2023 +0100

    libiberty: Use x86 HW optimized sha1

    Nick has approved this patch (+ small ld change to use it for --build-id=),
    so I'm commiting it to GCC as master as well.

    If anyone from ARM would be willing to implement it similarly with
    vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker
    speedup on those hosts as well, the intent in sha1.c was that
    sha1_hw_process_bytes, sha1_hw_process_block functions
    would be defined whenever
    defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT)
    but the body of sha1_hw_process_block and sha1_choose_process_bytes
    would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for
    the other arch support, similarly for any target attributes on
    sha1_hw_process_block if needed.

commit 01bc30b222a9d2ff0269325d9e367f8f1fcef942
Author: Mark Wielaard <mjw@redhat.com>
Date:   Wed Nov 15 20:27:08 2023 +0100

    Regenerate libiberty/aclocal.m4 with aclocal 1.15.1

    There is a new buildbot check that all autotool files are generated
    with the correct versions (automake 1.15.1 and autoconf 2.69).
    https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen

    Correct one file that was generated with the wrong version.

commit 879cf9ff45d94065d89e24b71c6b27c7076ac518
Author: Brendan Shanks <bshanks@codeweavers.com>
Date:   Thu Nov 9 21:01:07 2023 -0700

    [PATCH v3] libiberty: Use posix_spawn in pex-unix when available.

    Hi,

    This patch implements pex_unix_exec_child using posix_spawn when
    available.

    This should especially benefit recent macOS (where vfork just calls
    fork), but should have equivalent or faster performance on all
    platforms.
    In addition, the implementation is substantially simpler than the
    vfork+exec code path.

    Tested on x86_64-linux.

    v2: Fix error handling (previously the function would be run twice in
    case of error), and don't use a macro that changes control flow.

    v3: Match file style for error-handling blocks, don't close
    in/out/errdes on error, and check close() for errors.

commit 810bcc00156cefce7ad40fc9d8de6e43c3a04450
Author: Jason Merrill <jason@redhat.com>
Date:   Thu Aug 17 11:36:23 2023 -0400

    c++: constrained hidden friends [PR109751]

    r13-4035 avoided a problem with overloading of constrained hidden friends by
    checking satisfaction, but checking satisfaction early is inconsistent with
    the usual late checking and can lead to hard errors, so let's not do that
    after all.

    We were wrongly treating the different instantiations of the same friend
    template as the same function because maybe_substitute_reqs_for was failing
    to actually substitute in the case of a non-template friend.  But we don't
    actually need to do the substitution anyway, because [temp.friend] says that
    such a friend can't be the same as any other declaration.

    After fixing that, instead of a redefinition error we got an ambiguous
    overload error, fixed by allowing constrained hidden friends to coexist
    until overload resolution, at which point they probably won't be in the same
    ADL overload set anyway.

    And we avoid mangling collisions by following the proposed mangling for
    these friends as a member function with an extra 'F' before the name.  I
    demangle this by just adding [friend] to the name of the function because
    it's not feasible to reconstruct the actual scope of the function since the
    mangling ABI doesn't distinguish between class and namespace scopes.

            PR c++/109751