These tests fail when the testsuite is executed with -fstack-protector-strong.
To avoid this, this patch adds -fno-stack-protector to dg-options.

The list of FAILs is appended.  As you can see, it's mostly about
scan-assembler-* which are sort of expected to fail with the stack
protector on.

FAIL: gcc.target/aarch64/ldp_stp_unaligned_2.c scan-assembler-not mov\\tx[0-9]+, sp
FAIL: gcc.target/aarch64/shadow_call_stack_5.c scan-assembler-times stp\\\\tx29, x30, \\\\[sp\\\\] 1
FAIL: gcc.target/aarch64/shadow_call_stack_5.c scan-assembler ldr\\\\tx29, \\\\[sp\\\\]
FAIL: gcc.target/aarch64/shadow_call_stack_6.c scan-assembler-times str\\\\tx30, \\\\[sp\\\\] 1
FAIL: gcc.target/aarch64/shadow_call_stack_7.c scan-assembler-times stp\\\\tx19, x30, \\\\[sp, -[0-9]+\\\\]! 1
FAIL: gcc.target/aarch64/shadow_call_stack_7.c scan-assembler ldr\\\\tx19, \\\\[sp\\\\], [0-9]+
FAIL: gcc.target/aarch64/shadow_call_stack_8.c scan-assembler-times stp\\\\tx19, x20, \\\\[sp, -[0-9]+\\\\]! 1
FAIL: gcc.target/aarch64/shadow_call_stack_8.c scan-assembler ldp\\\\tx19, x20, \\\\[sp\\\\], [0-9]+
FAIL: gcc.target/aarch64/stack-check-12.c scan-assembler-times str\\\\txzr,  2
FAIL: gcc.target/aarch64/stack-check-prologue-11.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-12.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-13.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-13.c scan-assembler-times str\\\\s+x30, \\\\[sp\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-14.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-14.c scan-assembler-times str\\\\s+x30, \\\\[sp\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-15.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-15.c scan-assembler-times str\\\\s+x30, \\\\[sp\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-17.c check-function-bodies test1
FAIL: gcc.target/aarch64/stack-check-prologue-17.c check-function-bodies test2
FAIL: gcc.target/aarch64/stack-check-prologue-18.c check-function-bodies test1
FAIL: gcc.target/aarch64/stack-check-prologue-18.c check-function-bodies test2
FAIL: gcc.target/aarch64/stack-check-prologue-18.c check-function-bodies test3
FAIL: gcc.target/aarch64/stack-check-prologue-19.c check-function-bodies test1
FAIL: gcc.target/aarch64/stack-check-prologue-19.c check-function-bodies test2
FAIL: gcc.target/aarch64/stack-check-prologue-19.c check-function-bodies test3
FAIL: gcc.target/aarch64/stack-check-prologue-2.c scan-assembler-times str\\\\s+xzr, 0
FAIL: gcc.target/aarch64/stack-check-prologue-5.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-6.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/stack-check-prologue-8.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 2
FAIL: gcc.target/aarch64/stack-check-prologue-9.c scan-assembler-times str\\\\s+xzr, \\\\[sp, 1024\\\\] 1
FAIL: gcc.target/aarch64/test_frame_1.c scan-assembler-times str\\tx30, \\\\[sp, -[0-9]+\\\\]! 2
FAIL: gcc.target/aarch64/test_frame_10.c scan-assembler-times stp\\tx19, x30, \\\\[sp, [0-9]+\\\\] 1
FAIL: gcc.target/aarch64/test_frame_10.c scan-assembler ldp\\tx19, x30, \\\\[sp, [0-9]+\\\\]
FAIL: gcc.target/aarch64/test_frame_11.c scan-assembler-times stp\\tx29, x30, \\\\[sp, -[0-9]+\\\\]! 2
FAIL: gcc.target/aarch64/test_frame_13.c scan-assembler-times stp\\tx29, x30, \\\\[sp\\\\] 1
FAIL: gcc.target/aarch64/test_frame_15.c scan-assembler-times stp\\tx29, x30, \\\\[sp, [0-9]+\\\\] 1
FAIL: gcc.target/aarch64/test_frame_2.c scan-assembler-times stp\\tx19, x30, \\\\[sp, -[0-9]+\\\\]! 1
FAIL: gcc.target/aarch64/test_frame_2.c scan-assembler ldp\\tx19, x30, \\\\[sp\\\\], [0-9]+
FAIL: gcc.target/aarch64/test_frame_4.c scan-assembler-times stp\\tx19, x30, \\\\[sp, -[0-9]+\\\\]! 1
FAIL: gcc.target/aarch64/test_frame_4.c scan-assembler ldp\\tx19, x30, \\\\[sp\\\\], [0-9]+
FAIL: gcc.target/aarch64/test_frame_6.c scan-assembler-times str\\tx30, \\\\[sp\\\\] 1
FAIL: gcc.target/aarch64/test_frame_7.c scan-assembler-times stp\\tx19, x30, \\\\[sp] 1
FAIL: gcc.target/aarch64/test_frame_8.c scan-assembler-times str\\tx30, \\\\[sp, [0-9]+\\\\] 1
FAIL: gcc.target/aarch64/test_frame_8.c scan-assembler ldr\\tx30, \\\\[sp, [0-9]+\\\\]
FAIL: gcc.target/aarch64/sve/struct_vect_24.c scan-assembler-times cmp\\\\s+x[0-9]+, 61440 4
FAIL: gcc.target/aarch64/sve/struct_vect_24.c scan-assembler-times sub\\\\s+x[0-9]+, x[0-9]+, 61440 4
FAIL: gcc.target/aarch64/sve/struct_vect_24.c scan-assembler-times cmp\\s+x[0-9]+, 61440 4
FAIL: gcc.target/aarch64/sve/struct_vect_24.c scan-assembler-times sub\\s+x[0-9]+, x[0-9]+, 61440 4

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/ldp_stp_unaligned_2.c: Use -fno-stack-protector.
	* gcc.target/aarch64/shadow_call_stack_5.c: Likewise.
	* gcc.target/aarch64/shadow_call_stack_6.c: Likewise.
	* gcc.target/aarch64/shadow_call_stack_7.c: Likewise.
	* gcc.target/aarch64/shadow_call_stack_8.c: Likewise.
	* gcc.target/aarch64/stack-check-12.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-11.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-12.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-13.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-14.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-15.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-17.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-18.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-19.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-2.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-5.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-6.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-8.c: Likewise.
	* gcc.target/aarch64/stack-check-prologue-9.c: Likewise.
	* gcc.target/aarch64/sve/struct_vect_24.c: Likewise.
	* gcc.target/aarch64/test_frame_1.c: Likewise.
	* gcc.target/aarch64/test_frame_10.c: Likewise.
	* gcc.target/aarch64/test_frame_11.c: Likewise.
	* gcc.target/aarch64/test_frame_13.c: Likewise.
	* gcc.target/aarch64/test_frame_15.c: Likewise.
	* gcc.target/aarch64/test_frame_2.c: Likewise.
	* gcc.target/aarch64/test_frame_4.c: Likewise.
	* gcc.target/aarch64/test_frame_6.c: Likewise.
	* gcc.target/aarch64/test_frame_7.c: Likewise.
	* gcc.target/aarch64/test_frame_8.c: Likewise.

(cherry picked from commit 21257102)

libstdc++-v3/ChangeLog:

	PR libstdc++/111948
	* include/bits/ranges_util.h (subrange): Add constructor to
	_Size to avoid setting member in constructor.
	* testsuite/std/ranges/subrange/111948.cc: New test.

(cherry picked from commit 08448dc1)

This small change removes a branch when clearing a std::optional<T> for
types with no-op destructors. For types where the destructor can be
optimized away (e.g. because it's trivial, or empty and can be inlined)
the _M_destroy() function does nothing but set _M_engaged to false.
Setting _M_engaged=false unconditionally is cheaper than only doing it
when initially true, because it allows the compiler to remove a branch.

The compiler thinks it would be incorrect to unconditionally introduce a
store there, because it could conflict with reads in other threads, so
it won't do that optimization itself. We know it's safe to do because
we're in a non-const member function, so the standard forbids any
potentially concurrent calls to other member functions of the same
object. Making the store unconditional can't create a data race that
isn't already present in the program.

libstdc++-v3/ChangeLog:

	PR libstdc++/112480
	* include/std/optional (_Optional_payload_base::_M_reset): Set
	_M_engaged to false unconditionally.

(cherry picked from commit 2c492f99)

C++20 allows class types as non-type template parameters, but
std::integer_sequence explicitly disallows them. Enforce that.

libstdc++-v3/ChangeLog:

	PR libstdc++/112473
	* include/bits/utility.h (integer_sequence): Add static_assert.
	* testsuite/20_util/integer_sequence/112473.cc: New test.

(cherry picked from commit 0953497a)

All set_debug_format member functions should be guarded by the
__cpp_lib_formatting_ranges macro (which is not defined yet).

libstdc++-v3/ChangeLog:

	PR libstdc++/112832
	* include/std/format (formatter::set_debug_format): Ensure this
	member is defined conditionally for all specializations.
	* testsuite/std/format/formatter/112832.cc: New test.

(cherry picked from commit 3cd73543)

Use strerror_r instead of strerror when available, due to the latter not
being thread-safe. This is complicated by Glibc providing a GNU-specific
strerror_r which is not compatible with POSIX strerror_r, so we need to
dispatch on the return type.

Because we estimate the initial std::string buffer size we might end up
with excess capacity in the returned std::string. We can slightly tweak
the std::system_error constructors to make use of that excess capacity,
so that in some cases we require fewer allocations to construct the
std::system_error::what() string.

libstdc++-v3/ChangeLog:

	PR libstdc++/110133
	* include/std/system_error (system_error::system_error): Group
	arguments so that concatenation can reuse rvalue's capacity.
	* src/c++11/system_error.cc (strerror_string): New function.
	[_GLIBCXX_HAVE_STRERROR_R] (use_strerror_result): New functions.
	(generic_error_category::message): Use strerror_string.
	(system_error_category::message): Likewise.

(cherry picked from commit 51f94778)

The following testcase ICEs in the movabsq $(i32 << shift), r64 peephole2
I've added a while back to use smaller code than movabsq if possible.
If i32 is 0xfa1e0ff3 and shift is not divisible by 8, then it creates
an invalid insn (as 0xfa1e0ff3 CONST_INT is not allowed as
x86_64_immediate_operand nor x86_64_zext_immediate_operand), the peephole2
even triggers on it again and again (this time with shift 0) until it gives
up.

The following patch fixes that.  As ix86_endbr_immediate_operand needs a
CONST_INT and it is hopefully rare, I chose to use FAIL rather than handling
it in the condition (where I'd probably need to call ctz_hwi again etc.).

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

	PR target/112845
	* config/i386/i386.md (movabsq $(i32 << shift), r64 peephole2): FAIL
	if the new immediate is ix86_endbr_immediate_operand.

(cherry picked from commit e0786ca9)

The following testcase ICEs with RTL checking, because it sets if
XINT (SET_SRC (set), 1) is UNSPEC_SET_GOT without checking if SET_SRC (set)
is actually an UNSPEC, so any time we see any other insn with PARALLEL
and a SET in it which is not an UNSPEC we ICE during RTL checking or
access there some other union member as if it was an rt_int.
The rest is just small cleanup.

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

	PR target/112837
	* config/i386/i386.cc (ix86_elim_entry_set_got): Before checking
	for UNSPEC_SET_GOT check that SET_SRC is UNSPEC.  Use SET_SRC and
	SET_DEST macros instead of XEXP, rename vec variable to set.

	* gcc.dg/pr112837.c: New test.

(cherry picked from commit 4586d7d0)

The following testcase ICEs, because the signbit<mode>2 expander uses an
explicit SUBREG in the pattern around match_operand with register_operand
predicate.  If we are unlucky enough that expansion tries to expand it
with some SUBREG as operands[1], we have two nested SUBREGs in the IL,
which is not valid and causes ICE later.

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

	PR target/112816
	* config/i386/sse.md (signbit<mode>2): Force operands[1] into a REG.

	* gcc.target/i386/sse2-pr112816.c: New test.

(cherry picked from commit 994d6dc6)

foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll
during parsing calls maybe_constant_value unconditionally, which is
fine if !processing_template_decl, but can ICE otherwise.

While just calling fold_non_dependent_expr there instead could be enough
to fix the ICE (and I guess the right thing to do for backports if any),
I don't see a reason why we couldn't handle a dependent #pragma GCC unroll
argument as well, the unrolling isn't done in the FE and all the middle-end
cares about is that ANNOTATE_EXPR has a 1..65534 last operand when it is
annot_expr_unroll_kind.

So, the following patch changes all the unsigned short unroll arguments
to tree unroll (and thus avoids the tree -> unsigned short -> tree
conversions), does the type and value checking during parsing only if
the argument isn't dependent and repeats it during instantiation.

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

	PR c++/112795
gcc/cp/
	* parser.cc (cp_parser_pragma_unroll): Use fold_non_dependent_expr
	instead of maybe_constant_value.
gcc/testsuite/
	* g++.dg/ext/unroll-5.C: New test.

(cherry picked from commit b6c78fee)

In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fstdc_005fbit_005ffloor
I've noticed that while e.g. __builtin_stdc_bit_floor builtin is properly
rendered in bold and bigger size, for the __builtin_stdc_bit_width builtin
it is not the builtin name which is marked like that, but the keyword int
before it.  Also, seems such builtins are missing from the index.

I've read the texinfo docs and they seem to suggest in
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Line-Macros.html
that return types of functions with spaces in the return type should be
wrapped with {}s and we already use that e.g. in
@defbuiltin{{void *} __builtin_thread_pointer (void)}

The following patch adjusts builtins I found which contained one or two
spaces in the return type name (plus two spots which used 2 spaces after
single keyword return type instead of 1 which triggered my search regex as
well).

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

	* doc/extend.texi (__builtin_darn, __builtin_darn_raw,
	__builtin_ia32_vec_ext_v2di, __builtin_ia32_crc32qi,
	__builtin_ia32_crc32hi, __builtin_ia32_crc32si,
	__builtin_ia32_crc32di): Put {}s around return type with spaces in it.
	(__builtin_rx_mvfachi, __builtin_rx_mvfacmi): Remove superfluous
	whitespace.

(cherry picked from commit ff99671a)

The following testcase is miscompiled in GCC 14 because the
*jcc_bt<mode>_mask and *jcc_bt<SWI48:mode>_mask_1 patterns have just
one argument in (match_operator 0 "bt_comparison_operator" [...])
but as bt_comparison_operator is eq,ne, we need two.
The md readers don't warn about it, after all, some checks can
be done in the predicate rather than specified explicitly, and the
behavior is that anything is accepted as the second argument.

I went through all other i386.md match_operator uses and all others
looked right (extract_operator using 3 operands, all others 2).

I think we'll want to fix this at different spots in older releases
because I think the bug was introduced already in 2008, though most
likely just latent.

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

	PR target/111408
	* config/i386/i386.md (*jcc_bt<mode>_mask,
	*jcc_bt<mode>_mask_1): Add (const_int 0) as expected
	second operand of bt_comparison_operator.

	* gcc.c-torture/execute/pr111408.c: New test.

(cherry picked from commit 9866c98e)

The following testcase ICEs when dumping details.
When m_ssa_ranges vector is created, it is safe_grow_cleared (num_ssa_names),
but when when some new SSA_NAME is added, we strangely grow it to
num_ssa_names + 1 instead and later on the 3 argument dump method
iterates from 1 to m_ssa_ranges.length () - 1 and uses ssa_name (x)
on each; but because set_bb_range grew it one too much, ssa_name
(m_ssa_ranges.length () - 1) might be after the end of the ssanames
vector and ICE.

The fix grows the vector consistently only to num_ssa_names,
doesn't waste time checking m_ssa_ranges[0] because there is no
ssa_names (0), it is always NULL, before using ssa_name (x) checks
if we'll need it at all (we check later if m_ssa_ranges[x] is non-NULL,
so we might check it earlier as well) and also in the last loop
iterates until m_ssa_ranges.length () rather than num_ssa_names, I don't
see a reason for the inconsistency and in theory some SSA_NAME could be
added without set_bb_range called for it and the vector could be shorter
than the ssanames vector.

To actually fix the ICE, either the first hunk or the last 2 hunks
would be enough, but I think it doesn't hurt to change all the spots.

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

	PR tree-optimization/111967
	* gimple-range-cache.cc (block_range_cache::set_bb_range): Grow
	m_ssa_ranges to num_ssa_names rather than num_ssa_names + 1.
	(block_range_cache::dump): Iterate from 1 rather than 0.  Don't use
	ssa_name (x) unless m_ssa_ranges[x] is non-NULL.  Iterate to
	m_ssa_ranges.length () rather than num_ssa_names.

	* gcc.dg/tree-ssa/pr111967.c: New test.

(cherry picked from commit 5a0c302d)

The following testcase ICEs, because with -Wno-attributes=foo::no_sanitize
(but generally any other non-gnu namespace and some gnu well known attribute
name within that other namespace) the FEs don't really parse attribute
arguments of such attribute, but lookup_attribute_spec is non-NULL with
NULL handler and such attributes are added to DECL_ATTRIBUTES or
TYPE_ATTRIBUTES and then when e.g. middle-end does lookup_attribute
on a particular attribute and expects the attribute to mean something
and/or have a particular verified arguments, it can crash when seeing
the foreign attribute in there instead.

The following patch fixes that by never adding ignored attributes
to DECL_ATTRIBUTES/TYPE_ATTRIBUTES, previously that was the case just
for attributes in ignored namespace (where lookup_attribute_space
returned NULL).  We don't really know anything about those attributes,
so shouldn't pretend we know something about them, especially when
the arguments are error_mark_node or NULL instead of something that
would have been parsed.  And it would be really weird if we normally
ignore say [[clang::unused]] attribute, but when people use
-Wno-attributes=clang::unused we actually treated it as gnu::unused.
All the user asked for is suppress warnings about that attribute being
unknown.

The first hunk is just playing safe, I'm worried people could
-Wno-attributes=gnu::
and get various crashes with known GNU attributes not being actually
parsed and recorded (or worse e.g. when we tweak standard attributes
into GNU attributes and we wouldn't add those).
The -Wno-attributes= documentation says that it suppresses warning about
unknown attributes, so I think -Wno-attributes=gnu:: should prevent
warning about say [[gnu::foobarbaz]] attribute, but not about
[[gnu::unused]] because the latter is a known attribute.
The routine would return true for any scoped attribute in the ignored
namespace, with the change it ignores only unknown attributes in ignored
namespace, known ones in there will be ignored only if they have
max_length of -2 (e.g.. with
-Wno-attributes=gnu:: -Wno-attributes=gnu::foobarbaz).

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

	PR c/112339
	* attribs.cc (attribute_ignored_p): Only return true for
	attr_namespace_ignored_p if as is NULL.
	(decl_attributes): Never add ignored attributes.

	* c-c++-common/ubsan/Wno-attributes-1.c: New test.

(cherry picked from commit 533241c6)

The following testcase started FAILing recently after the
https://sourceware.org/git/?p=glibc.git;a=commit;h=64b1a44183a3094672ed304532bedb9acc707554
glibc change which marked vfscanf with nonnull (1) attribute.
While vfwscanf hasn't been marked similarly (strangely), the patch changes
that too.  By using va_arg one hides the value of it from the compiler
(volatile keyword would do too, or making the FILE* stream a function
argument, but then it might need to be guarded by #if or something).

2023-10-13  Jakub Jelinek  <jakub@redhat.com>

	* testsuite/tr1/8_c_compatibility/cstdio/functions.cc (test01):
	Initialize stream to va_arg(ap, FILE*) rather than 0.
	* testsuite/tr1/8_c_compatibility/cwchar/functions.cc (test01):
	Likewise.

(cherry picked from commit badb798f)

clearenv function just sets environ to NULL (after sometimes freeing it),
rather than setting it to a pointer to NULL, and our code was assuming
it is always non-NULL.

Fixed thusly, the change seems to be large but actually is just
+  if (environ)
     for (env = environ; *env != 0; env++)
plus reindentation.  I've also noticed the block after this for loop
was badly indented (too much) and fixed that too.

No testcase added, as it needs clearenv + dlopen.

2023-09-19  Jakub Jelinek  <jakub@redhat.com>

	PR libgomp/111413
	* env.c (initialize_env): Don't dereference environ if it is NULL.
	Reindent.

(cherry picked from commit 15345980)

In some cases involving a reduction expression with an overloaded reducer
subprogram, the accumulator type is not determined correctly. This can lead
to spurious compile-time errors.

gcc/ada/

	* exp_attr.adb (Expand_N_Attribute_Reference): In the case of a
	Reduce attribute reference, fix bugs in initializing Accum_Typ.
	The previous version was incorrect in the case where E1 refers to
	the first of multiple possible overload resolution candidates and
	that candidate does not turn out to be the right one. The previous
	version also had code to compute Accum_Typ via a different method
	if the initial computation turned out to yield a universal numeric
	type. Delete that initial computation and use the second method in
	all cases.

gcc/fortran/ChangeLog:

	PR fortran/111880
	* resolve.cc (resolve_common_vars): Do not call gfc_add_in_common
	for symbols that are USE associated or used in a submodule.

gcc/testsuite/ChangeLog:

	PR fortran/111880
	* gfortran.dg/pr111880.f90: New test.

(cherry picked from commit c9d029ba)

The associating entity in an ASSOCIATE construct has the TARGET attribute
if and only if the selector is a variable and has either the TARGET or
POINTER attribute (e.g. F2018:11.1.3.3).

gcc/fortran/ChangeLog:

	PR fortran/112764
	* primary.cc (gfc_variable_attr): Set TARGET attribute of associating
	entity dependent on TARGET or POINTER attribute of selector.

gcc/testsuite/ChangeLog:

	PR fortran/112764
	* gfortran.dg/associate_62.f90: New test.

(cherry picked from commit 951a3e37)

When we substitute the equivalence and it becomes shared, we can fail
to correctly update reg info used by LRA.  This can result in wrong
code generation, e.g. because of incorrect live analysis.  It can also
result in compiler crash as the pseudo survives RA.  This is what
exactly happened for the PR.  This patch solves this problem by
unsharing substituted equivalences.

gcc/ChangeLog:

	PR middle-end/111497
	* lra-constraints.cc (lra_constraints): Copy substituted
	equivalence.
	* lra.cc (lra): Change comment for calling unshare_all_rtl_again.

gcc/testsuite/ChangeLog:

	PR middle-end/111497
	* g++.target/i386/pr111497.C: new test.

(cherry picked from commit 3c23defe)

Make the utf8 manifest optional (on by default and
explicitly off with --disable-win32-utf8-manifest)
in the mingw hosts.

Also eliminate duplication between the 32-bit and
64-bit mingw hosts by putting them both in the
same branch and special-case only the 64-bit long
long setting.

PR mingw/111170
PR mingw/108865

Signed-off-by: Costas Argyris <costas.argyris@gmail.com>
Signed-off-by: Jonathan Yong <10walls@gmail.com>

gcc/Changelog:

	* configure.ac: Handle new --enable-win32-utf8-manifest
	option.
	* config.host: allow win32 utf8 manifest to be disabled
	by user.
	* configure: Regenerate.

(cherry picked from commit 4f1ebd54)

libstdc++-v3/ChangeLog:

	PR libstdc++/112607
	* include/std/format (basic_format_arg::_S_to_arg_type): Check
	value_type for basic_string_view and basic_string
	specializations.
	* testsuite/std/format/arguments/112607.cc: New test.

(cherry picked from commit 279e407a)

This is needed in order to compile it as a header-unit, which might be
desired because it's included by both <atomic> and <semaphore>.

libstdc++-v3/ChangeLog:

	* include/bits/atomic_wait.h: Include <stdint.h>.

(cherry picked from commit 6c8f2d3a)

This is more consistent with the specification in the standard.

libstdc++-v3/ChangeLog:

	* include/std/utility (in_range): Rename _Up parameter to _Res.

(cherry picked from commit 97fc8851)

potential_constant_expression for CALL_EXPR tests FUNCTION_POINTER_TYPE_P
on the callee rather than on the type of the callee, which means we
always pass want_rval=any when recursing and so may fail to identify a
non-constant function pointer callee as such.  Fixing this turns out to
further work around PR111703.

	PR c++/111703
	PR c++/107939

gcc/cp/ChangeLog:

	* constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>:
	Fix FUNCTION_POINTER_TYPE_P test.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-fn8.C: Extend test.
	* g++.dg/diagnostic/constexpr4.C: New test.

(cherry picked from commit 0077c0fb)

potential_constant_expression was incorrectly treating most local
variables from a constexpr function as constant because it wasn't
considering the 'now' parameter.  This patch fixes this by relaxing
its var_in_maybe_constexpr_fn checks accordingly, which turns out to
partially fix two recently reported regressions:

PR111703 is a regression caused by r11-550-gf65a3299a521a4 for restricting
constexpr evaluation during warning-dependent folding.  The mechanism is
intended to restrict only constant evaluation of the instantiated
non-dependent expression, but it also ends up restricting constant
evaluation occurring during instantiation of the expression, in particular
when instantiating the converted argument 'x' (a VIEW_CONVERT_EXPR) into
a copy constructor call.  This seems like a flaw in the mechanism, though
I don't know if we want to fix the mechanism or get rid of it completely
since the original testcases which motivated the mechanism are fixed more
simply by r13-1225-gb00b95198e6720.  In any case, this patch partially
fixes this by making us correctly treat 'x' as non-constant which prevents
the problematic warning-dependent folding from occurring at all.

PR112269 is caused by r14-4796-g3e3d73ed5e85e7 for merging tsubst_copy
into tsubst_copy_and_build.  tsubst_copy used to exit early when 'args'
was empty, behavior which that commit deliberately didn't preserve.
This early exit masked the fact that COMPLEX_EXPR wasn't handled by
tsubst at all, and is a tree code that apparently we could see during
warning-dependent folding on some targets.  A complete fix is to add
handling for this tree code in tsubst_expr, but this patch should fix
the reported testsuite failures since the COMPLEX_EXPRs that crop up
in <complex> are considered non-constant expressions after this patch.

	PR c++/111703
	PR c++/112269

gcc/cp/ChangeLog:

	* constexpr.cc (potential_constant_expression_1) <case VAR_DECL>:
	Only consider var_in_maybe_constexpr_fn if 'now' is false.
	<case INDIRECT_REF>: Likewise.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-fn8.C: New test.

(cherry picked from commit 6665a857)