Autoreconf-2.72 warns about obsolete macros. This patch aims at removing
the noise from a future upgrade to autoreconf-2.72 or later. This is in
no a way a complete patch allowing the upgrade to autoreconf-2.72.

- AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS
  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/
  autoconf.html#index-AC_005fGNU_005fSOURCE-1
- AC_CONFIG_HEADER by AC_CONFIG_HEADERS
  https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-
  Macros.html#index-AM_005fCONFIG_005fHEADER

Those fixes were originally submitted in a patch series in binutils.
https://inbox.sourceware.org/binutils/878qthm6a0.fsf@gentoo.org/

libiberty/ChangeLog:

	* configure: Regenerate.
	* configure.ac: Fix autoupdate warnings.

libiberty/getopt.c file is defining _NO_PROTO, which causes
conflicting declarations for the functions in AIX header files
like stdio.h & stdlib.h.
Looks like _NO_PROTO define were added long back and conflicting
declarations were always present until C23 standard uncovered it.

Remove the block defining _NO_PROTO as both Tru64 UNIX (ex-OSF/1)
and AIX 3.2 is no more supported.

libiberty/ChangeLog:

	* getopt.c: Remove _NO_PROTO block

The patch reuses the configuration for LTO from ix86 and adds the
aarch64 architecture to the list of supported COFF headers.

gcc/ChangeLog:

	* config/aarch64/cygming.h (TARGET_ASM_LTO_START): New.
	(TARGET_ASM_LTO_END): Likewise.
	* config/i386/cygming.h (TARGET_ASM_LTO_START): Update.
	(TARGET_ASM_LTO_END): Likewise.
	* config/i386/i386-protos.h (i386_pe_asm_lto_start): Delete.
	(i386_pe_asm_lto_end): Likewise.
	* config/mingw/winnt.cc (i386_pe_asm_lto_start): Rename
	into ...
	(mingw_pe_asm_lto_start): ... this.
	(i386_pe_asm_lto_end): Rename into ...
	(mingw_pe_asm_lto_end): ... this.
	* config/mingw/winnt.h (mingw_pe_asm_lto_start): New.
	(mingw_pe_asm_lto_end): Likewise.

libiberty/ChangeLog:

	* simple-object-coff.c: Add aarch64.

Some of the function definitions used K&R style definitions (but not all).
This just moves them all to be ANSI C

Bootstrapped and tested on x86_64-linux-gnu.

libiberty/ChangeLog:

	* testsuite/test-demangle.c (get_line): Change K&R style
	definition into ANSI C90 definitions.
	(fail): Likewise.
	(main): Likewise.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>

These comment typos were found in the valgrind fork of libiberty
demangle code.

libiberty/ChangeLog:

	* cplus-dem.c: Change preceeded to preceded.

include/ChangeLog:

	* safe-ctype.h: Change accidently to accidentally.

cp-demangle.c does not build when CP_DEMANGLE_DEBUG is defined since
r13-2887-gb04208895fed34. This trivial patch fixes the issue.

libiberty/ChangeLog:

	* cp-demangle.c (d_dump): Fix compilation when CP_DEMANGLE_DEBUG
	is defined.

cat abc.C
  #define A(n) struct T##n {} t##n;
  #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
  #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
  #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9)
  #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9)
  E(1) E(2) E(3)
  int main () { return 0; }
./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c
./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2
(not included in testsuite as it takes a while to compile) FAILs with
lto-wrapper: fatal error: Too many copied sections: Operation not supported
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

The following patch fixes that.  Most of the 64K+ section support for
reading and writing was already there years ago (and especially reading used
quite often already) and a further bug fixed in it in the PR104617 fix.

Yet, the fix isn't solely about removing the
  if (new_i - 1 >= SHN_LORESERVE)
    {
      *err = ENOTSUP;
      return "Too many copied sections";
    }
5 lines, the missing part was that the function only handled reading of
the .symtab_shndx section but not copying/updating of it.
If the result has less than 64K-epsilon sections, that actually wasn't
needed, but e.g. with -fdebug-types-section one can exceed that pretty
easily (reported to us on WebKitGtk build on ppc64le).
Updating the section is slightly more complicated, because it basically
needs to be done in lock step with updating the .symtab section, if one
doesn't need to use SHN_XINDEX in there, the section should (or should be
updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would
be overwise stored but couldn't fit.  But repeating due to that all the
symtab decisions what to discard and how to rewrite it would be ugly.

So, the patch instead emits the .symtab_shndx section (or sections) last
and prepares the content during the .symtab processing and in a second
pass when going just through .symtab_shndx sections just uses the saved
content.

2024-09-07  Jakub Jelinek  <jakub@redhat.com>

	PR lto/116614
	* simple-object-elf.c (SHN_COMMON): Align comment with neighbouring
	comments.
	(SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for
	consistency.
	(simple_object_elf_find_sections): Formatting fixes.
	(simple_object_elf_fetch_attributes): Likewise.
	(simple_object_elf_attributes_merge): Likewise.
	(simple_object_elf_start_write): Likewise.
	(simple_object_elf_write_ehdr): Likewise.
	(simple_object_elf_write_shdr): Likewise.
	(simple_object_elf_write_to_file): Likewise.
	(simple_object_elf_copy_lto_debug_section): Likewise.  Don't fail for
	new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy
	over .symtab_shndx sections, though emit those last and compute their
	section content when processing associated .symtab sections.  Handle
	simple_object_internal_read failure even in the .symtab_shndx reading
	case.

After the commit:

  commit 5e1d530d (gcc-buildargv)
  Date:   Sat Feb 10 11:22:13 2024 +0000

      libiberty/buildargv: handle input consisting of only white space

The function only_whitespace (in argv.c) was no longer being called.
Lets delete it.

There should be no user visible changes after this commit.

2024-07-29  Andrew Burgess  <aburgess@redhat.com>

libiberty/

	* argv.c (only_whitespace): Delete.

GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.

I have recently been working to improve this area of GDB, and noticed
some unexpected behaviour to the libiberty function buildargv, when
the input is a string consisting only of white space.

What I observe is that if the input to buildargv is a string
containing only white space, then buildargv will return an argv list
containing a single empty argument, e.g.:

  char **argv = buildargv (" ");
  assert (*argv[0] == '\0');
  assert (argv[1] == NULL);

We get the same output from buildargv if the input is a single space,
or multiple spaces.  Other white space characters give the same
results.

This doesn't seem right to me, and in fact, there appears to be a work
around for this issue in expandargv where we have this code:

  /* If the file is empty or contains only whitespace, buildargv would
     return a single empty argument.  In this context we want no arguments,
     instead.  */
  if (only_whitespace (buffer))
    {
      file_argv = (char **) xmalloc (sizeof (char *));
      file_argv[0] = NULL;
    }
  else
    /* Parse the string.  */
    file_argv = buildargv (buffer);

I think that the correct behaviour in this situation is to return an
empty argv array, e.g.:

  char **argv = buildargv (" ");
  assert (argv[0] == NULL);

And it turns out that this is a trivial change to buildargv.  The diff
does look big, but this is because I've re-indented a block.  Check
with 'git diff -b' to see the minimal changes.  I've also removed the
work around from expandargv.

When testing this sort of thing I normally write the tests first, and
then fix the code.  In this case test-expandargv.c has sort-of been
used as a mechanism for testing the buildargv function (expandargv
does call buildargv most of the time), however, for this particular
issue the work around in expandargv (mentioned above) masked the
buildargv bug.

I did consider adding a new test-buildargv.c file, however, this would
have basically been a copy & paste of test-expandargv.c (with some
minor changes to call buildargv).  This would be fine now, but feels
like we would eventually end up with one file not being updated as
much as the other, and so test coverage would suffer.

Instead, I have added some explicit buildargv testing to the
test-expandargv.c file, this reuses the test input that is already
defined for expandargv.

Of course, once I removed the work around from expandargv then we now
do always call buildargv from expandargv, and so the bug I'm fixing
would impact both expandargv and buildargv, so maybe the new testing
is redundant?  I tend to think more testing is always better, so I've
left it in for now.

2024-07-16  Andrew Burgess  <aburgess@redhat.com>

libiberty/

	* argv.c (buildargv): Treat input of only whitespace as an empty
	argument list.
	(expandargv): Remove work around for intput that is only
	whitespace.
	* testsuite/test-expandargv.c: Add new tests 10, 11, and 12.
	Extend testing to call buildargv in more cases.

GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.

I have recently been working to improve this area of GDB, and have
tracked done some of the unexpected behaviour to the libiberty
function buildargv, and how it handles backslash escapes.

For reference, I've been mostly reading:

  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

The issues that I would like to fix are:

  1. Backslashes within single quotes should not be treated as an
  escape, thus: '\a' should split to \a, retaining the backslash.

  2. Backslashes within double quotes should only act as an escape if
  they are immediately before one of the characters $ (dollar),
  ` (backtick), " (double quote), ` (backslash), or \n (newline).  In
  all other cases a backslash should not be treated as an escape
  character.  Thus: "\a" should split to \a, but "\$" should split to
  $.

  3. A backslash-newline sequence should be treated as a line
  continuation, both the backslash and the newline should be removed.

I've updated libiberty and also added some tests.  All the existing
libiberty tests continue to pass, but I'm not sure if there is more
testing that should be done, buildargv is used within lto-wraper.cc,
so maybe there's some testing folk can suggest that I run?

2024-07-16  Andrew Burgess  <aburgess@redhat.com>

libiberty/

	* argv.c (buildargv): Backslashes within single quotes are
	literal, backslashes only escape POSIX defined special characters
	within double quotes, and backslashed newlines should act as line
	continuations.
	* testsuite/test-expandargv.c: Add new tests 7, 8, and 9.

Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names.  However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low.  The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).

This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276

libiberty
	* cplus-dem.c (cplus_demangle): Try the D demangler with
	"auto" format.
	* testsuite/d-demangle-expected: Add --format=auto test.

Like in r12-7519-g027e30414492d50feb2854aff38227b14300dc4b, I've done
git grep -v 'long long\|optab optab\|template template\|double double' | grep ' \([a-zA-Z]\+\) \1 '

This is just part of the changes, mostly for non-gcc directories.
I'll try to get to the rest soon.  Obviously, the above command also
finds cases which are correct as is and shouldn't be changed, so one
needs to manually inspect everything.

I'd hope most of it is pretty obvious, but the config/ and libstdc++-v3/
hunks include a tweak in a license wording, though other copies of the
similar license have the wording right.

2024-04-02  Jakub Jelinek  <jakub@redhat.com>

	* Makefile.tpl: Fix duplicated words; returns returns ->
	returns.
config/
	* lcmessage.m4: Fix duplicated words; can can -> can,
	package package -> package.
libdecnumber/
	* decCommon.c (decFinalize): Fix duplicated words in
	comment; the the -> the.
libgcc/
	* unwind-dw2-fde.c (struct fde_accumulator): Fix duplicated
	words in comment; is is -> is.
libgfortran/
	* configure.host: Fix duplicated words; the the -> the.
libgm2/
	* configure.host: Fix duplicated words; the the -> the.
libgomp/
	* libgomp.texi (OpenMP 5.2): Fix duplicated words; with with ->
	with.
	(omp_target_associate_ptr): Fix duplicated words; either either ->
	either.
	(omp_init_allocator): Fix duplicated words; be be -> be.
	(omp_realloc): Fix duplicated words; is is -> is.
	(OMP_ALLOCATOR): Fix duplicated words; other other -> other.
	* priority_queue.h (priority_queue_multi_p): Fix duplicated words;
	to to -> to.
libiberty/
	* regex.c (byte_re_match_2_internal): Fix duplicated words in comment;
	next next -> next.
	* dyn-string.c (dyn_string_init): Fix duplicated words in comment;
	of of -> of.
libitm/
	* beginend.cc (GTM::gtm_thread::begin_transaction): Fix duplicated
	words in comment; not not -> not to.
libobjc/
	* init.c (duplicate_classes): Fix duplicated words in comment; in in
	-> in.
	* sendmsg.c (__objc_prepare_dtable_for_class): Fix duplicated words
	in comment; the the -> the.
	* encoding.c (objc_layout_structure): Likewise.
libstdc++-v3/
	* acinclude.m4: Fix duplicated words; file file -> file can.
	* configure.host: Fix duplicated words; the the -> the.
libvtv/
	* vtv_rts.cc (vtv_fail): Fix duplicated words; to to -> to.
	* vtv_fail.cc (vtv_fail): Likewise.

r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes.  The return value from the generic exec_child is examined
and needs to be < 0 to signal an error. However, the unix flavour of
this routine is returning the PID value set from the posix_spawn{p}.

This latter value is undefined per the manual pages for both Darwin
and Linux, and it seems Darwin, at least, sets the value to some
usually positive number (presumably the PID that would have been used
if the fork had succeeded).

The fix proposed here is to set the pid = -1 in the relevant error
paths.

	PR other/113957

libiberty/ChangeLog:

	* pex-unix.c (pex_unix_exec_child): Set pid = -1 in the error
	paths, since that is used to signal an erroneous outcome for
	the routine.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

The following removes the TBAA violation present in iterative_hash.
As we eventually LTO that it's important to fix.  This also improves
code generation for the >= 12 bytes loop by using | to compose the
4 byte words as at least GCC 7 and up can recognize that pattern
and perform a 4 byte load while the variant with a + is not
recognized (not on trunk either), I think we have an enhancement bug
for this somewhere.

Given we reliably merge and the bogus "optimized" path might be
only relevant for archs that cannot do misaligned loads efficiently
I've chosen to keep a specialization for aligned accesses.

libiberty/
	* hashtab.c (iterative_hash): Remove TBAA violating handling
	of aligned little-endian case in favor of just keeping the
	aligned case special-cased.  Use | for composing a larger word.

When writing the HOST_SIZE_T_PRINT_UNSIGNED incremental patch,
my first bootstrap failed on i686-linux.  That is because I've also had
@@ -1344,8 +1344,10 @@ adjust_field_rtx_def (type_p t, options_
            }

          subfields = create_field (subfields, t,
-                                   xasprintf (".fld[%lu].%s",
-                                              (unsigned long) aindex,
+                                   xasprintf (".fld["
+                                              HOST_SIZE_T_PRINT_UNSIGNED
+                                              "].%s",
+                                              (fmt_size_t) aindex,
                                               subname));
          subfields->opt = nodot;
          if (t == note_union_tp)
hunk in gengtype.cc.  While sprintf obviously can print in this case %llu
with fmt_size_t being unsigned long long (that is another bug I'll fix
incrementally), seems libiberty_vprintf_buffer_size
can't deal with that, it ignores h, hh, l, ll and L modifiers and
unconditionally, estimates 30 chars as upper bounds for integers (that is
fine) and then uses (void) va_arg (ap, int); to skip over the argument
regardless if it was %d, %ld, %lld, %hd, %hhd etc.
Now, on x86_64 that happens to work fine probably for all of those,
on ia32 for everything but %lld, because it then skips just one half
of the long long argument; now as there is %s after it, it will try to
compute strlen not from the pointer argument corresponding to %s, but
from the most significant half of the previous long long argument.

So, the following patch attempts not to completely ignore the modifiers,
but figure out from them whether to va_arg an int (used for h and hh as
well), or long, or long long, or size_t, or ptrdiff_t - added support for
z and t there, plus for Windows I64.  And also %Lf etc. for long double.

2024-02-12  Jakub Jelinek  <jakub@redhat.com>

	* vprintf-support.c (libiberty_vprintf_buffer_size): Handle
	properly l, ll, z, t or on _WIN32 I64 modifiers for diouxX
	and L modifier for fFgGeE.

The following patch attempts to implement what apparently clang++
implemented for explicit object member function mangling, but nobody
actually proposed in patch form in
https://github.com/itanium-cxx-abi/cxx-abi/issues/148

2024-01-13  Jakub Jelinek  <jakub@redhat.com>

gcc/cp/
	* mangle.cc (write_nested_name): Mangle explicit object
	member functions with H as per
	https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal.
gcc/testsuite/
	* g++.dg/abi/mangle79.C: New test.
include/
	* demangle.h (enum demangle_component_type): Add
	DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
libiberty/
	* cp-demangle.c (FNQUAL_COMPONENT_CASE): Add case for
	DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
	(d_dump): Handle DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
	(d_nested_name): Parse H after N in nested name.
	(d_count_templates_scopes): Handle
	DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
	(d_print_mod): Likewise.
	(d_print_function_type): Likewise.
	* testsuite/demangle-expected: Add tests for explicit object
	member functions.

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.

2023-12-05  Jakub Jelinek  <jakub@redhat.com>

	* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): Verify __get_cpuid and
	__get_cpuid_count are not implicitly declared.
	* configure: Regenerated.

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.

2023-12-03  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	libiberty:
	* pex-unix.c (pex_unix_wait): Change return type to pid_t.

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.

gcc/cp/ChangeLog:

	* cp-tree.h (TEMPLATE_ARGS_TYPE_CONSTRAINT_P): New.
	(get_concept_check_template): Declare.
	* constraint.cc (combine_constraint_expressions)
	(finish_shorthand_constraint): Use UNKNOWN_LOCATION.
	* pt.cc (convert_generic_types_to_packs): Likewise.
	* mangle.cc (write_constraint_expression)
	(write_tparms_constraints, write_type_constraint)
	(template_parm_natural_p, write_requirement)
	(write_requires_expr): New.
	(write_encoding): Mangle trailing requires-clause.
	(write_name): Pass parms to write_template_args.
	(write_template_param_decl): Factor out from...
	(write_closure_template_head): ...here.
	(write_template_args): Mangle non-natural parms
	and requires-clause.
	(write_expression): Handle REQUIRES_EXPR.

include/ChangeLog:

	* demangle.h (enum demangle_component_type): Add
	DEMANGLE_COMPONENT_CONSTRAINTS.

libiberty/ChangeLog:

	* cp-demangle.c (d_make_comp): Handle
	DEMANGLE_COMPONENT_CONSTRAINTS.
	(d_count_templates_scopes): Likewise.
	(d_print_comp_inner): Likewise.
	(d_maybe_constraints): New.
	(d_encoding, d_template_args_1): Call it.
	(d_parmlist): Handle 'Q'.
	* testsuite/demangle-expected: Add some constraint tests.

libstdc++-v3/ChangeLog:

	* include/std/bit: Avoid builtins in requires-clauses.
	* include/std/variant: Likewise.

gcc/testsuite/ChangeLog:

	* g++.dg/abi/mangle10.C: Disable compat aliases.
	* g++.dg/abi/mangle52.C: Specify ABI 18.
	* g++.dg/cpp2a/class-deduction-alias3.C
	* g++.dg/cpp2a/class-deduction-alias8.C:
	Avoid builtins in requires-clauses.
	* g++.dg/abi/mangle-concepts1.C: New test.
	* g++.dg/abi/mangle-ttp1.C: New test.

This patch

commit bf4f40cc
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.

2023-11-29  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	config:
	* hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): Require
	AC_CANONICAL_TARGET.

	libiberty:
	* configure.ac (GCC_CHECK_ASSEMBLER_HWCAP): Invoke.
	* configure, aclocal.m4: Regenerate.
	* Makefile.in (COMPILE.c): Add HWCAP_CFLAGS.

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.

2023-11-28  Jakub Jelinek  <jakub@redhat.com>

include/
	* sha1.h (sha1_process_bytes_fn): New typedef.
	(sha1_choose_process_bytes): Declare.
libiberty/
	* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check.
	* sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h
	and cpuid.h.
	(sha1_hw_process_bytes, sha1_hw_process_block,
	sha1_choose_process_bytes): New functions.
	* config.in: Regenerated.
	* configure: Regenerated.