The problem is that the predicated subtype does not inherit all the required
attributes of a string subtype with a static predicate.

gcc/ada/
	* sem_ch3.adb (Analyze_Subtype_Declaration): Remove a short-circuit
	for subtypes without aspects when it comes to predicates.
	* sem_util.adb (Inherit_Predicate_Flags): Deal with private subtypes
	whose full view is an Itype.

We are still ICEing on the generic lambda version of the testcase from
this PR, even after r13-6743-g6f90de97634d6f, due to the by-ref capture
of the constant local variable 'dim' being considered value-dependent
when regenerating the lambda (at which point processing_template_decl is
set since the lambda is generic), which prevents us from constant folding
its uses.  Later during prune_lambda_captures we end up not thoroughly
walking the body of the lambda and overlook the (non-folded) uses of
'dim' within the array bound and using-decls.

We could fix this by making prune_lambda_captures walk the body of the
lambda more thoroughly so that it finds these uses of 'dim', but ideally
we should be able to constant fold all uses of 'dim' ahead of time and
prune the implicit capture after all.

To that end this patch makes value_dependent_expression_p return false
for such by-ref captures of constant local variables, allowing their
uses to get constant folded ahead of time.  It seems we just need to
disable the predicate's conservative early exit for reference variables
(added by r5-5022-g51d72abe5ea04e) when DECL_HAS_VALUE_EXPR_P.  This
effectively makes us treat by-value and by-ref captures more consistently
when it comes to value dependence.

	PR c++/108975

gcc/cp/ChangeLog:

	* pt.cc (value_dependent_expression_p) <case VAR_DECL>:
	Suppress conservative early exit for reference variables
	when DECL_HAS_VALUE_EXPR_P.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/lambda/lambda-const11a.C: New test.

(cherry picked from commit 3d674e29)

	PR sanitizer/111736
	* asan.cc (asan_protect_global): Do not protect globals
	in non-generic address-space.

(cherry picked from commit 7e404978)

Apparently when looking for "signbit<mode>2" vector expanders, I've only
looked at sse.md and forgot mmx.md, which has another one and the
following patch still ICEd.

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

	PR target/112816
	* config/i386/mmx.md (signbitv2sf2): Force operands[1] into a REG.

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

(cherry picked from commit 80e1375e)

The following testcase ICEs because we aren't careful enough with
alloc_size attribute.  We do check that such an argument exists
(although wouldn't handle correctly functions with more than INT_MAX
arguments), but didn't check that it is scalar integer, the ICE is
trying to fold_convert a structure to sizetype.

Given that the attribute can also appear on non-prototyped functions
where the arguments aren't known, I don't see how the FE could diagnose
that and because we already handle the case where argument doesn't exist,
I think we should also verify the argument is scalar integer convertible
to sizetype.  Furthermore, given this is not just in diagnostics but
used for code generation, I think it is better to punt on arguments with
larger precision then sizetype, the upper bits are then truncated.

The patch also fixes some formatting issues and avoids duplication of the
fold_convert, plus removes unnecessary check for if (arg1 >= 0), that is
always the case after if (arg1 < 0) return ...;

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

	PR tree-optimization/113013
	* tree-object-size.cc (alloc_object_size): Return size_unknown if
	corresponding argument(s) don't have integral type or have integral
	type with higher precision than sizetype.  Don't check arg1 >= 0
	uselessly.  Compare argument indexes against gimple_call_num_args
	in unsigned type rather than int.  Formatting fixes.

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

(cherry picked from commit 5347263b)

In many cases we just specify types for the builtin arguments, in other cases
types and names with @var{name} syntax, and in other case with just name.

Shall we tweak that somehow?  If the argument names are unimportant, perhaps
it is fine to leave that out, but shouldn't we always use @var{...} around
the parameter names when specified?

On Fri, Dec 01, 2023 at 10:43:57AM -0700, Sandra Loosemore wrote:
> Yup.  The Texinfo manual says:  "When using @deftypefn command and
> variations, you should mark parameter names with @var to distinguish these
> from data type names, keywords, and other parts of the literal syntax of the
> programming language."

Here is a patch which does that (but not adding types to where they were
missing, that will be harder to search for).

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

	* doc/extend.texi (__sync_fetch_and_add, __sync_fetch_and_sub,
	__sync_fetch_and_or, __sync_fetch_and_and, __sync_fetch_and_xor,
	__sync_fetch_and_nand, __sync_add_and_fetch, __sync_sub_and_fetch,
	__sync_or_and_fetch, __sync_and_and_fetch, __sync_xor_and_fetch,
	__sync_nand_and_fetch, __sync_bool_compare_and_swap,
	__sync_val_compare_and_swap, __sync_lock_test_and_set,
	__sync_lock_release, __atomic_load_n, __atomic_load, __atomic_store_n,
	__atomic_store, __atomic_exchange_n, __atomic_exchange,
	__atomic_compare_exchange_n, __atomic_compare_exchange,
	__atomic_add_fetch, __atomic_sub_fetch, __atomic_and_fetch,
	__atomic_xor_fetch, __atomic_or_fetch, __atomic_nand_fetch,
	__atomic_fetch_add, __atomic_fetch_sub, __atomic_fetch_and,
	__atomic_fetch_xor, __atomic_fetch_or, __atomic_fetch_nand,
	__atomic_test_and_set, __atomic_clear, __atomic_thread_fence,
	__atomic_signal_fence, __atomic_always_lock_free,
	__atomic_is_lock_free, __builtin_add_overflow,
	__builtin_sadd_overflow, __builtin_saddl_overflow,
	__builtin_saddll_overflow, __builtin_uadd_overflow,
	__builtin_uaddl_overflow, __builtin_uaddll_overflow,
	__builtin_sub_overflow, __builtin_ssub_overflow,
	__builtin_ssubl_overflow, __builtin_ssubll_overflow,
	__builtin_usub_overflow, __builtin_usubl_overflow,
	__builtin_usubll_overflow, __builtin_mul_overflow,
	__builtin_smul_overflow, __builtin_smull_overflow,
	__builtin_smulll_overflow, __builtin_umul_overflow,
	__builtin_umull_overflow, __builtin_umulll_overflow,
	__builtin_add_overflow_p, __builtin_sub_overflow_p,
	__builtin_mul_overflow_p, __builtin_alloca,
	__builtin_alloca_with_align, __builtin_alloca_with_align_and_max,
	__builtin_speculation_safe_value, __builtin_nan, __builtin_nand32,
	__builtin_nand64, __builtin_nand128, __builtin_nanf, __builtin_nanl,
	__builtin_nanf@var{n}, __builtin_nanf@var{n}x, __builtin_nans,
	__builtin_nansd32, __builtin_nansd64, __builtin_nansd128,
	__builtin_nansf, __builtin_nansl, __builtin_nansf@var{n},
	__builtin_nansf@var{n}x, __builtin_ffs, __builtin_clz, __builtin_ctz,
	__builtin_clrsb, __builtin_popcount, __builtin_parity,
	__builtin_bswap16, __builtin_bswap32, __builtin_bswap64,
	__builtin_bswap128, __builtin_extend_pointer,
	__builtin_goacc_parlevel_id, __builtin_goacc_parlevel_size, vec_clrl,
	vec_clrr, vec_mulh, vec_mul, vec_div, vec_dive, vec_mod,
	__builtin_rx_mvtc): Use @var{...} around parameter names.
	(vec_rl, vec_sl, vec_sr, vec_sra): Likewise.  Use @var{...} also
	around A, B and R in description.

(cherry picked from commit 23795106)

The following testcase is miscompiled because two ubsan instrumentations
run into each other.
The first one is the shift instrumentation.  Before the C++ FE calls
it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects
in them aren't evaluated multiple times.  And, ubsan_instrument_shift
itself uses unshare_expr on any uses of the operands to make sure further
modifications in them don't affect other copies of them (the only not
unshared ones are the one the caller then uses for the actual operation
after the instrumentation, which means there is no tree sharing).

Now, if there are side-effects in the first operand like say function
call, cp_save_expr wraps it into a SAVE_EXPR, and ubsan_instrument_shift
in this mode emits something like
if (..., SAVE_EXPR <foo ()>, SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR <foo ()>, ...);
and caller adds
SAVE_EXPR <foo ()> << SAVE_EXPR <op1>
after it in a COMPOUND_EXPR.  So far so good.

If there are no side-effects and cp_save_expr doesn't create SAVE_EXPR,
everything is ok as well because of the unshare_expr.
We have
if (..., SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., ptr->something[i], ...);
and
ptr->something[i] << SAVE_EXPR <op1>
where ptr->something[i] is unshared.

In the testcase below, the !x->s[j] ? 1 : 0 expression is wrapped initially
into a SAVE_EXPR though, and unshare_expr doesn't unshare SAVE_EXPRs nor
anything used in them for obvious reasons, so we end up with:
if (..., SAVE_EXPR <!(bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 1 : 0>, SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR <!(bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 1 : 0>, ...);
and
SAVE_EXPR <!(bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 1 : 0> << SAVE_EXPR <op1>
So far good as well.  But later during cp_fold of the SAVE_EXPR we find
out that VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 0 : 1 is actually
invariant (has TREE_READONLY set) and so cp_fold simplifies the above to
if (..., SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., (bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 0 : 1, ...);
and
((bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 0 : 1) << SAVE_EXPR <op1>
with the s[j] ARRAY_REFs and other expressions shared in between the two
uses (and obviously the expression optimized away from the COMPOUND_EXPR in
the if condition.

Then comes another ubsan instrumentation at genericization time,
this time to instrument the ARRAY_REFs with strict bounds checking,
and replaces the s[j] in there with s[.UBSAN_BOUNDS (0B, SAVE_EXPR<j>, 8), SAVE_EXPR<j>]
As the trees are shared, it does that just once though.
And as the if body is gimplified first, the SAVE_EXPR<j> is evaluated inside
of the if body and when it is used again after the if, it uses a potentially
uninitialized value of j.1 (always uninitialized if the shift count isn't
out of bounds).

The following patch fixes that by unshare_expr unsharing the folded argument
of a SAVE_EXPR if we've folded the SAVE_EXPR into an invariant and it is
used more than once.

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

	PR sanitizer/112727
	* cp-gimplify.cc (cp_fold): If SAVE_EXPR has been previously
	folded, unshare_expr what is returned.

	* c-c++-common/ubsan/pr112727.c: New test.

(cherry picked from commit 6ddaf06e)

We ICE on the following testcase when wi::multiple_of_p is called on
widest_int 1 and -128 with UNSIGNED.  I still need to work on the
actual wide-int.cc issue, the latest patch attached to the PR regressed
bitint-{38,39}.c, so will need to debug that, but there is a clear bug
on the fold-const.cc side as well - widest_int is a signed representation
by definition, using UNSIGNED with it certainly doesn't match what was
intended, because -128 as the second operand effectively means unsigned
131072 bit 0xfffff............ffff80 integer, not the signed char -128
that appeared in the source.

In the INTEGER_CST case a few lines above this we already use
    case INTEGER_CST:
      if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
        return false;
      return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
                                SIGNED);
so I think using SIGNED with widest_int is best there (compared to the
other choices in the PR).

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

	PR middle-end/112733
	* fold-const.cc (multiple_of_p): Pass SIGNED rather than
	UNSIGNED for wi::multiple_of_p on widest_int arguments.

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

(cherry picked from commit 5c95bf94)

These tests are expected to run interactively, with the output checked
by eye. Nobody ever does that, but we can at least use dg-output to
check that the output is as expected.

libstdc++-v3/ChangeLog:

	* testsuite/27_io/objects/char/2.cc: Use dg-output.
	* testsuite/27_io/objects/wchar_t/2.cc: Use dg-output.

(cherry picked from commit 0c773209)

I got the order of arguments to std::format_to wrong. It was in a
discarded statement, for a case which wasn't being tested.

libstdc++-v3/ChangeLog:

	* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix order
	of arguments to std::format_to.
	* testsuite/20_util/duration/io.cc: Test subsecond duration with
	floating-point rep.

(cherry picked from commit 2ef5200a)

gcc/ChangeLog:

	* config/i386/driver-i386.cc (host_detect_local_cpu): Do not
	set Grand Ridge depending on RAO-INT.
	* config/i386/i386.h: Remove PTA_RAOINT from PTA_GRANDRIDGE.
	* doc/invoke.texi: Adjust documentation.

The change in r14-6468-ga01462ae8bafa8 was only supposed to apply to %C
formats, not %Y.

libstdc++-v3/ChangeLog:

	* include/bits/chrono_io.h (__formatter_chrono::_M_C_y_Y): Do
	not round century down for %Y formats.

(cherry picked from commit ad537ccd)

This backports just the tests from r14-6469-g52de6aa1a85822 because the
regression wasn't present on this branch, but we can still use the
tests.

libstdc++-v3/ChangeLog:

	* testsuite/std/format/functions/format.cc: Check for expected
	output for char and bool arguments.
	* testsuite/std/format/string.cc: Check that 0 filling is
	rejected for character and string formats.

(cherry picked from commit 52de6aa1)

During discussion of LWG 4022 I noticed that we do not correctly
implement floored division for the century. We were just truncating
towards zero, rather than applying the floor function. For negative
values that rounds the wrong way.

libstdc++-v3/ChangeLog:

	* include/bits/chrono_io.h (__formatter_chrono::_M_C_y_Y): Fix
	rounding for negative centuries.
	* testsuite/std/time/year/io.cc: Check %C for negative years.

(cherry picked from commit a01462ae)

Don't assume it's AVX_U128_CLEAN after call_insn whose abi.mode_clobber(V4DImode) deosn't contains all SSE_REGS.

If the function desn't clobber any sse registers or only clobber
128-bit part, then vzeroupper isn't issued before the function exit.
the status not CLEAN but ANY after the function.

Also for sibling_call, it's safe to issue an vzeroupper. Also there
could be missing vzeroupper since there's no mode_exit for
sibling_call_p.

gcc/ChangeLog:

	PR target/112891
	* config/i386/i386.cc (ix86_avx_u128_mode_after): Return
	AVX_U128_ANY if callee_abi doesn't clobber all_sse_regs to
	align with ix86_avx_u128_mode_needed.
	(ix86_avx_u128_mode_needed): Return AVX_U128_ClEAN for
	sibling_call.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/pr112891.c: New test.
	* gcc.target/i386/pr112891-2.c: New test.

is_really_empty_class is liable to crash when it gets an incomplete
or dependent type.  Since r11-557, we pass the yet-uninstantiated
class type S<0> of the PARM_DECL s to is_really_empty_class -- because
of the potential_rvalue_constant_expression -> is_rvalue_constant_expression
change in cp_parser_constant_expression.  Here we're not parsing
a template so we did not check COMPLETE_TYPE_P as we should.

It should work to complete the type before checking COMPLETE_TYPE_P.

	PR c++/110106

gcc/cp/ChangeLog:

	* constexpr.cc (potential_constant_expression_1): Try to complete the
	type when !processing_template_decl.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/noexcept80.C: New test.

(cherry picked from commit e36d1994)

Here we are wrongly parsing

  int y(auto(42));

which uses the C++23 cast-to-prvalue feature, and initializes y to 42.
However, we were treating the auto as an implicit template parameter.

Fixing the auto{42} case is easy, but when auto is followed by a (,
I found the fix to be much more involved.  For instance, we cannot
use cp_parser_expression, because that can give hard errors.  It's
also necessary to disambiguate 'auto(i)' as 'auto i', not a cast.
auto(), auto(int), auto(f)(int), auto(*), auto(i[]), auto(...), etc.
are all function declarations.

This patch rectifies that by undoing the implicit function template
modification.  In the test above, we should notice that the parameter
list is ill-formed, and since we've synthesized an implicit template
parameter, we undo it by calling abort_fully_implicit_template.  Then,
we'll parse the "(auto(42))" as an initializer.

	PR c++/112410

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_direct_declarator): Maybe call
	abort_fully_implicit_template if it turned out the parameter list was
	ill-formed.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/auto-fncast13.C: New test.
	* g++.dg/cpp23/auto-fncast14.C: New test.

(cherry picked from commit 70060dad)

Since r8-509, we'll no longer create a static temporary var for
the initializer '{ 1, 2 }' for num in the attached test because
the code in finish_compound_literal is now guarded by
'&& fcl_context == fcl_c99' but it's fcl_functional here.  This
causes us to reject num as non-constant when evaluating it in
a template.

Jason's idea was to treat num as value-dependent even though it
actually isn't.  This patch implements that suggestion.

We weren't marking objects whose type is an empty class type
constant.  This patch changes that so that v_d_e_p doesn't need
to check is_really_empty_class.

Co-authored-by: Jason Merrill <jason@redhat.com>

	PR c++/109876

gcc/cp/ChangeLog:

	* decl.cc (cp_finish_decl): Set TREE_CONSTANT when initializing
	an object of empty class type.
	* pt.cc (value_dependent_expression_p) <case VAR_DECL>: Treat a
	constexpr-declared non-constant variable as value-dependent.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/constexpr-template12.C: New test.
	* g++.dg/cpp1z/constexpr-template1.C: New test.
	* g++.dg/cpp1z/constexpr-template2.C: New test.

(cherry picked from commit b5138df9)

On macOS 14, a guard in <math.h> changed:

-- MacOSX13.3.sdk/usr/include/math.h 2023-04-19 01:54:44
+++ MacOSX14.0.sdk/usr/include/math.h 2023-08-01 08:42:43
@@ -22,0 +23 @@
+
@@ -43 +44 @@
-#if __FLT_EVAL_METHOD__ == 0
+#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == -1
@@ -49 +50 @@
-#elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1
+#elif __FLT_EVAL_METHOD__ == 2

Therefore the darwin_flt_eval_method fixincludes fix doesn't match any
longer, leading to a large number of testsuite failures like

/private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed/math.h:69:5:
error: #error "Unsupported value of __FLT_EVAL_METHOD__."

where __FLT_EVAL_METHOD__ = 16.

This patch adjusts the fix to allow for both forms.

Tested with make check in fixincludes on x86_64-apple-darwin23.0.0 and
verifying that <math.h> has indeed been fixed as expected.

(backport of 93f803d5)

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

fixincludes:
	* inclhack.def (darwin_flt_eval_method): Handle macOS 14 guard
	variant.
	* fixincl.x: Regenerate.
	* tests/base/math.h [DARWIN_FLT_EVAL_METHOD_CHECK]: Update test.

gcc/fortran/ChangeLog:

	PR fortran/93762
	PR fortran/100651
	* trans-array.cc (gfc_trans_deferred_array): Add presence check
	for optional deferred-length character dummy arguments.
	* trans-expr.cc (gfc_conv_missing_dummy): The character length for
	deferred-length dummy arguments is passed by reference, so that
	its value can be returned.  Adjust handling for optional dummies.

gcc/testsuite/ChangeLog:

	PR fortran/93762
	PR fortran/100651
	* gfortran.dg/optional_deferred_char_1.f90: New test.

(cherry picked from commit 27ce74fa)

As noted in the PR, we support both features required for the 202110L
value, so we should define it with that value.

libstdc++-v3/ChangeLog:

	PR libstdc++/111826
	* include/std/format (__cpp_lib_format): Update value.
	* include/std/version (__cpp_lib_format): Likewise.
	* testsuite/std/format/functions/format.cc: Update expected
	value.

(cherry picked from commit cdf45e00)

This local typedef for uintptr_t was accidentally named uint64_t,
probably from a careless code completion shortcut. We don't need the
typedef at all since it's only used once. Just use __UINTPTR_TYPE__
directly instead.

libstdc++-v3/ChangeLog:

	* include/std/format (_Iter_sink<charT, contiguous_iterator>):
	Remove uint64_t local type.

(cherry picked from commit cab0083d)

In r14-5922-g6c8f2d3a08bc01 I added <stdint.h> to <bits/atomic_wait.h>,
so that uintptr_t is declared if that header is compiled as a header
unit. I used <stdint.h> because that's what <atomic> already includes,
so it seemed simpler to be consistent. However, this means that name
lookup for uintptr_t in <bits/atomic_wait.h> depends on whether
<cstdint> has been included by another header first. Whether name lookup
finds std::uintptr_t or ::uintptr_t will depend on include order. This
causes problems when compiling modules with Clang:

bits/atomic_wait.h:251:7: error: 'std::__detail::__waiter_pool_base' has different definitions in different modules; first difference is defined here found method '_S_for' with body
      _S_for(const void* __addr) noexcept
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bits/atomic_wait.h:251:7: note: but in 'tm.<global>' found method '_S_for' with different body
      _S_for(const void* __addr) noexcept
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By including <cstdint> we would ensure that name lookup always finds the
name in namespace std. Alternatively, we can stop including <stdint.h>
for those types, so that we don't declare the entire contents of
<stdint.h> when we only need a couple of types from it. This patch does
the former, which is appropriate for backporting.

libstdc++-v3/ChangeLog:

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

(cherry picked from commit 2f512f6f)

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)