c++: non-dep array list-init w/ non-triv dtor [PR109899]

The get_target_expr call added in r12-7069-g119cea98f66476 causes us
for the below testcase to call build_vec_delete in a template context,
which builds a templated destructor call and checks expr_noexcept_p for
it, which ICEs because the call has templated form.

Much of the work of build_vec_delete however is code generation and thus
will just get discarded in a template context, and that includes the
code guarded by expr_noexcept_p.  So this patch narrowly fixes this ICE
by eliding the expr_noexcept_p call when in a template context.

PR c++/109899

gcc/cp/ChangeLog:

* init.cc (build_vec_delete_1): Assume expr_noexcept_p returns
false in a template context.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-array21.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit d33c3b5ac9b9b3e314ae9118d483ade7e91a80a5)

AVR: target/113156 - Fix ICE due to missing "Save" on -m[long-]double= options.

Multilib options -mdouble= and -mlong-double= are not orthogonal:
TARGET_HANDLE_OPTION = avr-common.cc::avr_handle_option() sets them
such that  sizeof(double) <= sizeof(long double)  is always true.

gcc/
PR target/113156
* config/avr/avr.opt (-mdouble, -mlong-double): Add "Save" flag.
(-mbranch-cost): Set "Optimization" flag.

(cherry picked from commit f1b0b1e4454d160564090a4cc1fa649ccefdcb1e)

Daily bump.

PR testsuite/106879 FAIL: gcc.dg/vect/bb-slp-layout-19.c on powerpc64

On P7, option -mno-allow-movmisalign is added during testing, which
prevents slp happen on the case.

Like PR65484 and PR87306, this patch use vect_hw_misalign to guard
the case on powerpc targets.

gcc/testsuite/ChangeLog:

PR testsuite/106879
* gcc.dg/vect/bb-slp-layout-19.c: Modify to guard the check with
vect_hw_misalign on POWERs.

Daily bump.

libgfortran: Emit a space at beginning of internal unit NML.

PR libgfortran/113223

libgfortran/ChangeLog:

* io/write.c (namelist_write): If internal_unit precede with space.

gcc/testsuite/ChangeLog:

* gfortran.dg/dtio_25.f90: Update.
* gfortran.dg/namelist_57.f90: Update.
* gfortran.dg/namelist_65.f90: Update.

(cherry picked from commit add995ec117d756e61d207041cd32f937c1a1cd9)

Daily bump.

libgcc, nios2: Fix exception handling on nios2 with -fpic

Exception handling on nios2-linux-gnu with -fpic has been broken since
revision 790854ea7670f11c14d431c102a49181d2915965, "Use _dl_find_object
in _Unwind_Find_FDE".  For whatever reason, this doesn't work on nios2.

Nios2 uses the GOT address as the base for DW_EH_PE_datarel
relocations in PIC; see my previous fix to make this work, revision
2d33dcfe9f0494c9b56a8d704c3d27c5a4329ebc, "Support for GOT-relative
DW_EH_PE_datarel encoding".  So this may be a horrible bug in the ABI
or in my interpretation of it or just glibc's implementation of
_dl_find_object for this target, but there's existing code out there
that does things this way; and realistically, nobody is going to
re-engineer this now that the vendor has EOL'ed the nios2
architecture.  So, just skip over the code trying to use
_dl_find_object on this target and fall back to the way that works.

libgcc/ChangeLog
* unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Do not try to use
_dl_find_object on nios2; it doesn't work.

(cherry picked from commit cc9cac9f073a9517f5b7fcffcb7c28b166339491)

AVR: Work around "sequence of 3 consecutive punctuation characters" warning.

gcc/
* config/avr/avr.cc (avr_handle_addr_attribute): Move "..." from
format string to %s argument.

(cherry picked from commit 549ea1487a534d0eef6a424075264ba542514c3d)

libstdc++: Fix incorrect PR number in comment

libstdc++-v3/ChangeLog:

* include/std/format (__format::_Arg_store): Fix PR number in
comment. Simplify preprocessor code.

(cherry picked from commit e9035183a20af10a80a97b57accb76699c9c2530)

Daily bump.

libstdc++: Fix spelling mistake in new doc addition

libstdc++-v3/ChangeLog:

* doc/xml/manual/evolution.xml: Fix spelling.
* doc/html/manual/api.html: Regenerate.

(cherry picked from commit 9bac1d7839f129f93f159c27adaf472ee3ab23a2)

libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator [PR112477]

Now that _M_Detach do not reset iterator _M_version value we need to reset it when
the iterator is attached to a new sequence. Even if this sequence is null like when
assigning a value-initialized iterator. In this case _M_version shall be reset to 0.

libstdc++-v3/ChangeLog:

PR libstdc++/112477
* src/c++11/debug.cc
(_Safe_iterator_base::_M_attach): Reset _M_version to 0 if attaching to null
sequence.
(_Safe_iterator_base::_M_attach_single): Likewise.
(_Safe_local_iterator_base::_M_attach): Likewise.
(_Safe_local_iterator_base::_M_attach_single): Likewise.
* testsuite/23_containers/map/debug/112477.cc: New test case.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

libstdc++: Document addition of libstdc++exp.a

The API Evolution section of the manual should mention when the
libstdc++exp.a library was added.

libstdc++-v3/ChangeLog:

* doc/xml/manual/evolution.xml: Document addition of
libstdc++exp.a.
* doc/html/*: Regenerate.

(cherry picked from commit a3babd7db769d0aeccb96a494ba3ac3e6f005181)

tree-object-size: Always set computed bit for bdos [PR113012]

It is always safe to set the computed bit for dynamic object sizes at
the end of collect_object_sizes_for because even in case of a dependency
loop encountered in nested calls, we have an SSA temporary to actually
finish the object size expression.  The reexamine pass for dynamic
object sizes is only for propagation of unknowns and gimplification of
the size expressions, not for loop resolution as in the case of static
object sizes.

gcc/ChangeLog:

PR tree-optimization/113012
* tree-object-size.cc (compute_builtin_object_size): Expand
comment for dynamic object sizes.
(collect_object_sizes_for): Always set COMPUTED bitmap for
dynamic object sizes.

gcc/testsuite/ChangeLog:

PR tree-optimization/113012
* gcc.dg/ubsan/pr113012.c: New test case.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
(cherry picked from commit 576c1fc4401a9dae9757ac2e4fa37d05e130fa3d)

libstdc++: Fix error handling in filesystem::equivalent [PR113250]

This patch made std::filesystem::equivalent correctly throw an exception
when either path does not exist as per [fs.op.equivalent]/4.

PR libstdc++/113250

libstdc++-v3/ChangeLog:

* src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&.
* src/filesystem/ops.cc (fs::equivalent): Likewise.
* testsuite/27_io/filesystem/operations/equivalent.cc: Handle
error codes.
* testsuite/experimental/filesystem/operations/equivalent.cc:
Likewise.

Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit df147e2ee7199d33d66959c6509ce9c21072077f)

Daily bump.

libstdc++: Add Filesystem TS and std::stacktrace symbols to libstdc++exp.a

This consolidates the three static archives for extensions into one, so
that -lstdc++exp can be used to provide the definitions of all unstable
library features.

For this gcc-13 backport libstdc++_libbacktrace.a is still installed,
but its contents are duplicated in libstdc++exp.a. This means that users
can start using -lstdc++exp with GCC 13.3 if they want, but existing
Makefiles can continue to use -lstdc++_libbacktrace for any GCC 13.x
release.

The libstdc++fs.a archive is still installed, but its contents are
duplicated in libstdc++exp.a now. This means -lstdc++exp can be used
instead of -lstdc++fs. For targets using the GNU linker we should
consider replacing libstdc++fs.a with a linker script that does
INPUT(libstdc++exp.a).

The tests for <experimental/filesystem> could be changed to use
-lstdc++exp instead of -lstdc++fs, which would allow removing
src/filesystem/.libs from the LDFLAGS in scripts/testsuite_flags.in,
but that can be done at a later date.

libstdc++-v3/ChangeLog:

* doc/html/manual/*: Regenerate.
* doc/xml/manual/using.xml: Update documentation on linking.
* scripts/testsuite_flags.in: Adjust LDFLAGS to find
libstdc++exp instead of libstdc++_libbacktrace.
* src/c++20/Makefile.am: Fix comment.
* src/c++20/Makefile.in: Regenerate.
* src/experimental/Makefile.am: Use LIBADD to include other
libraries.
* src/experimental/Makefile.in: Regenerate.
* testsuite/19_diagnostics/stacktrace/current.cc: Adjust
dg-options to use -lstdc++exp.
* testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
* testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
Likewise.

(cherry picked from commit b96b554592c5cbb6a2c1797ffcb5706fd295f4fd)

Daily bump.

Fix internal error on function call returning extension of limited interface

The problem occurs when this function call is the expression of a return in
a function returning the limited interface; in this peculiar case, there is
a mismatch between the callee, which has BIP formals but is not a BIP call,
and the caller, which is a BIP function, that is spotted by an assertion.

This is fixed by restoring the semantics of Is_Build_In_Place_Function_Call,
which returns again true only for calls to BIP functions, introducing the
Is_Function_Call_With_BIP_Formals predicate, which also returns true for
calls to functions with BIP formals that are not BIP functions, and moving
down the assertion in Expand_Simple_Function_Return.

gcc/ada/
PR ada/112781
* exp_ch6.ads (Is_Build_In_Place_Function): Adjust description.
* exp_ch6.adb (Is_True_Build_In_Place_Function_Call): Delete.
(Is_Function_Call_With_BIP_Formals): New predicate.
(Is_Build_In_Place_Function_Call): Restore original semantics.
(Expand_Call_Helper): Adjust conditions guarding the calls to
Add_Dummy_Build_In_Place_Actuals to above renaming.
(Expand_N_Extended_Return_Statement): Adjust to above renaming.
(Expand_Simple_Function_Return): Likewise.  Move the assertion
to after the transformation into an extended return statement.
(Make_Build_In_Place_Call_In_Allocator): Remove unreachable code.
(Make_Build_In_Place_Call_In_Assignment): Likewise.

gcc/testsuite/
* gnat.dg/bip_prim_func2.adb: New test.
* gnat.dg/bip_prim_func2_pkg.ads, gnat.dg/bip_prim_func2_pkg.adb:
New helper package.

ada: Fix unsupported dispatching constructor call

Add dummy build-in-place parameters when a BIP function does not
require the BIP parameters but it is a dispatching operation that
inherited them.

gcc/ada/

* einfo-utils.adb (Underlying_Type): Protect recursion call
against non-available attribute Etype.
* einfo.ads (Protected_Subprogram): Fix typo in documentation.
* exp_ch3.adb (BIP_Function_Call_Id): New subprogram.
(Expand_N_Object_Declaration): Improve code that evaluates if the
object is initialized with a BIP function call.
* exp_ch6.adb (Is_True_Build_In_Place_Function_Call): New
subprogram.
(Add_Task_Actuals_To_Build_In_Place_Call): Add dummy actuals if
the function does not require the BIP task actuals but it is a
dispatching operation that inherited them.
(Build_In_Place_Formal): Improve code to avoid never-ending loop
if the BIP formal is not found.
(Add_Dummy_Build_In_Place_Actuals): New subprogram.
(Expand_Call_Helper): Add calls to
Add_Dummy_Build_In_Place_Actuals.
(Expand_N_Extended_Return_Statement): Adjust assertion.
(Expand_Simple_Function_Return): Adjust assertion.
(Make_Build_In_Place_Call_In_Allocator): No action needed if the
called function inherited the BIP extra formals but it is not a
true BIP function.
(Make_Build_In_Place_Call_In_Assignment): Ditto.
* exp_intr.adb (Expand_Dispatching_Constructor_Call): Remove code
reporting unsupported case (since this patch adds support for it).
* sem_ch6.adb (Analyze_Subprogram_Body_Helper): Adding assertion
to ensure matching of BIP formals when setting the
Protected_Formal field of a protected subprogram to reference the
corresponding extra formal of the subprogram that implements it.
(Might_Need_BIP_Task_Actuals): New subprogram.
(Create_Extra_Formals): Improve code adding inherited extra
formals.

Fix internal error on function call returning extension of limited interface

This is a regression present on the mainline and 13 branch, in the form of a
series of internal errors (3) on a function call returning the extension of
a limited interface.

This is only a partial fix for the first two assertion failures; the third
one is the most problematic and will be dealt with separately.

The first issue is in Instantiate_Type, where we use Base_Type in a specific
case to compute the ancestor of a derived type, which will later trigger the
assertion on line 16960 of sem_ch3.adb since Parent_Base and Generic_Actual
are the same node.  This is changed to use Etype like in other cases around.

The second issue is an unprotected use of Designated_Type on type T in
Analyze_Explicit_Dereference, while another use in an equivalent context
is guarded by Is_Access_Type a few lines above.

gcc/ada
PR ada/112781
* sem_ch12.adb (Instantiate_Type): Use Etype instead of Base_Type
consistently to retrieve the ancestor for a derived type.
* sem_ch4.adb (Analyze_Explicit_Dereference): Test Is_Access_Type
consistently before accessing Designated_Type.

Fix internal error on anonymous access type equality

This is a small regression present on the mainline and 13 branch, in the
form of an internal error in gigi on anonymous access type equality.  We
now need to also accept them for anonymous access types that point to
compatible object subtypes in the language sense.

gcc/ada/
* gcc-interface/utils2.cc (build_binary_op) <EQ_EXPR>: Relax
assertion for regular pointer types.

gcc/testsuite/
* gnat.dg/specs/anon4.ads: New test.

Fix segfault during delay slot scheduling pass

This is a small regression present on the mainline and 13 branch, although
the underlying problem has probably been there for ages, in the form of a
segfault during the delay slot scheduling pass, for a function that falls
through to exit without any instruction generated for the end of function.

gcc/
PR rtl-optimization/113140
* reorg.cc (fill_slots_from_thread): If we are to branch after the
last instruction of the function, create an end label.

gcc/testsuite/
* g++.dg/opt/delay-slot-2.C: New test.

Daily bump.

libstdc++: Add additional tests for std::format with wide strings

Backport the extra tests from r14-3300-g023a62b77f999b.

libstdc++-v3/ChangeLog:

* testsuite/std/format/functions/format.cc: Add more checks for
wstring formatting of arithmetic types.

libstdc++: Implement P2909R4 ("Dude, where's my char?") for C++20

This change ensures that char and wchar_t arguments are formatted
consistently when using integer presentation types. This avoids
non-portable std::format output that depends on whether char and wchar_t
happen to be signed or unsigned on the target. Formatting '\xff' as an
integer will now always format 255 and not sometimes -1. This was
approved in Kona 2023 as a DR for C++20 so the change is implemented
unconditionally.

Also make character formatters check for _Pres_c explicitly and call
_M_format_character directly. This avoid the overhead of calling format
and _S_to_character and then calling _M_format_character anyway.

libstdc++-v3/ChangeLog:

* include/std/format (formatter<C, C>::format): Check for
_Pres_c and call _M_format_character directly. Cast C to its
unsigned equivalent for formatting as an integer.
(formatter<char, wchar_t>::format): Likewise.
(basic_format_arg(T&)): Store char arguments as unsigned char
for formatting to a wide string.
(__cpp_lib_format_uchar): Define.
* include/std/version (__cpp_lib_format_uchar): Define.
* testsuite/std/format/functions/format.cc: Adjust test. Check
formatting of characters using all integer presentation types.

(cherry picked from commit 74a0dab18292bef54f316eb086112332befbc6a7)

AVR: PR target/112952: Fix attribute "address", "io" and "io_low"

so they work with all combinations of -f[no-]data-sections -f[no-]common.
The patch also improves some diagnostics and adds additional checks, for
example these attributes must only be applied to variables in static storage.

gcc/
PR target/112952
* config/avr/avr.cc (avr_handle_addr_attribute): Also print valid
range when diagnosing attribute "io" and "io_low" are out of range.
(avr_eval_addr_attrib): Don't ICE on empty address at that place.
(avr_insert_attributes): Reject if attribute "address", "io" or "io_low"
in contexts other than static storage.
(avr_asm_output_aligned_decl_common): Move output of decls with
attribute "address", "io", and "io_low" to...
(avr_output_addr_attrib): ...this new function.
(avr_asm_asm_output_aligned_bss): Remove output for decls with
attribute "address", "io", and "io_low".
(avr_encode_section_info): Rectify handling of decls with attribute
"address", "io", and "io_low".

gcc/testsuite/
PR target/112952
* gcc.target/avr/attribute-io.h: New file.
* gcc.target/avr/pr112952-0.c: New test.
* gcc.target/avr/pr112952-1.c: New test.
* gcc.target/avr/pr112952-2.c: New test.
* gcc.target/avr/pr112952-3.c: New test.

(cherry picked from commit c131b1d5da412b9b0f0681fc5704cdc9b7cafb04)

Daily bump.

Daily bump.

libstdc++: Do not use __is_convertible unconditionally [PR113241]

The new __is_convertible built-in should only be used after checking
that it's supported.

libstdc++-v3/ChangeLog:

PR libstdc++/113241
* include/std/type_traits (is_convertible_v): Guard use of
built-in with preprocessor check.

(cherry picked from commit 57fa5b60bbbf8038b8a699d2bcebd2a9b2e29aa4)

libstdc++: Fix std::char_traits<C>::move [PR113200]

The current constexpr implementation of std::char_traits<C>::move relies
on being able to compare the pointer parameters, which is not allowed
for unrelated pointers. We can use __builtin_constant_p to determine
whether it's safe to compare the pointers directly. If not, then we know
the ranges must be disjoint and so we can use char_traits<C>::copy to
copy forwards from the first character to the last. If the pointers can
be compared directly, then we can simplify the condition for copying
backwards to just two pointer comparisons.

libstdc++-v3/ChangeLog:

PR libstdc++/113200
* include/bits/char_traits.h (__gnu_cxx::char_traits::move): Use
__builtin_constant_p to check for unrelated pointers that cannot
be compared during constant evaluation.
* testsuite/21_strings/char_traits/requirements/113200.cc: New
test.

(cherry picked from commit 15cc291887dc9dd92b2c93f4545e20eb6c190122)

Daily bump.

Daily bump.

Daily bump.

libstdc++: testsuite: Reduce max_size_type.cc exec time [PR113175]

The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
inadvertently increased the execution time of this test by over 5x due
to making the two main loops actually run in the signed_p case instead
of being dead code.

To compensate, this patch cuts the relevant loops' range [-1000,1000] by
10x as proposed in the PR.  This shouldn't significantly weaken the test
since the same important edge cases are still checked in the smaller range
and/or elsewhere.  On my machine this reduces the test's execution time by
roughly 10x (and 1.6x relative to before r14-205).

PR testsuite/113175

libstdc++-v3/ChangeLog:

* testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce
'limit' to 100 from 1000 and adjust 'log2_limit' accordingly.
(test03): Likewise.

(cherry picked from commit a138b99646a5551c53b860648521adb5bfe8c2fa)

Daily bump.

Daily bump.

Daily bump.

Daily bump.

Daily bump.

Daily bump.

Daily bump.

Fortran: fix argument passing to CONTIGUOUS,TARGET dummy [PR97592]

gcc/fortran/ChangeLog:

PR fortran/97592
* trans-expr.cc (gfc_conv_procedure_call): For a contiguous dummy
with the TARGET attribute, the effective argument may still be
contiguous even if the actual argument is not simply-contiguous.
Allow packing to be decided at runtime by _gfortran_internal_pack.

gcc/testsuite/ChangeLog:

PR fortran/97592
* gfortran.dg/contiguous_15.f90: New test.

(cherry picked from commit 5060825aa78b3da036df6437390fd42d094d8f15)

Daily bump.

Daily bump.

Daily bump.

Daily bump.

MIPS: Don't add nan2008 option for -mtune=native

Users may wish just use -mtune=native for performance tuning only.
Let's don't make trouble for its case.

gcc/

* config/mips/driver-native.cc (host_detect_local_cpu):
don't add nan2008 option for -mtune=native.

MIPS: Put the ret to the end of args of reconcat [PR112759]

The function `reconcat` cannot append string(s) to NULL,
as the concat process will stop at the first NULL.

Let's always put the `ret` to the end, as it may be NULL.
We keep use reconcat here, due to that reconcat can make it
easier if we add more hardware features detecting, for example
by hwcap.

gcc/

PR target/112759
* config/mips/driver-native.cc (host_detect_local_cpu):
Put the ret to the end of args of reconcat.

Daily bump.

Daily bump.

Daily bump.

ada: Fix internal error on call with parameter of predicated subtype

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.

c++: value dependence of by-ref lambda capture [PR108975]

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 3d674e29d7f89bf93fcfcc963ff0248c6347586d)

Daily bump.

sanitizer/111736 - skip ASAN for globals in alternate address-space

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

(cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)

i386: Fix mmx.md signbit expanders [PR112816]

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 80e1375ed7a7a05a5a60a57e72c5ad5eba005798)

Daily bump.

tree-object-size: Robustify alloc_size attribute handling [PR113013]

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 5347263b347d02e875879ca40ca6e289ac178919)

Daily bump.

Daily bump.

Daily bump.

extend.texi: Mark builtin arguments with @var{...}

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 237951066bc52559e43e76172baa7d1dec4cee75)

c++: Unshare folded SAVE_EXPR arguments during cp_fold [PR112727]

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 6ddaf06e375e1c15dcda338697ab6ea457e6f497)

fold-const: Fix up multiple_of_p [PR112733]

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 5c95bf945c632925efba86dd5dceccdb9da8884c)

libstdc++: Add dg-output to two tests

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 0c773209fc9d0b5fa04f4055bdc2ff9746a1999d)

libstdc++: Fix %S format of duration with floating-point rep

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 2ef5200a6fb7311074904a1b4bf7ce750618a068)

i386: Remove RAO-INT from Grand Ridge

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.

Daily bump.

Daily bump.

libstdc++: Fix regression in std::format output of %Y for negative years

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 ad537ccd525fd3af759febd6c0936f82de808a70)

libstdc++: Backport some std::format test improvements

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 52de6aa1a8582208b519b6998389d3a801b0de7b)

libstdc++: Fix std::format output of %C for negative years

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 a01462ae8bafa86e7df47a252917ba6899d587cf)

Daily bump.

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.

c++: fix ICE with is_really_empty_class [PR110106]

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 e36d1994051122fc6e1f8c728fbd109a59e0a822)

c++: fix parsing with auto(x) [PR112410]

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 70060dadfbf0d0af5f4cab5f3aff3223a4523606)

c++: wrong error with static constexpr var in tmpl [PR109876]

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 b5138df96a93d3b5070c88b8617eabd38cb24ab6)

Daily bump.

fixincludes: Update darwin_flt_eval_method for macOS 14

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 93f803d53b5ccaabded9d7b4512b54da81c1c616)

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.

Daily bump.

Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]

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 27ce74fa23c93c1189c301993cd19ea766e6bdb5)

Daily bump.

libstdc++: Fix value of __cpp_lib_format macro [PR111826]

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 cdf45e00a936a76a785c592c9730f24ef1ac25cd)

libstdc++: Fix misleading typedef name in <format>

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 cab0083dc72dfd22a1b2016b068f9313beb7f091)

libstdc++: Use <cstdint> instead of <stdint.h> in <bits/atomic_wait.h>

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 2f512f6fcdd55296daff3e01a250d866491014e6)

Daily bump.

Daily bump.

aarch64: add -fno-stack-protector to tests

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 2125710245d64ff6edff7ebd339caf4698fdd89d)

Daily bump.

libstdc++: Add workaround to std::ranges::subrange [PR111948]

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 08448dc146b6dd32383d64ab491a594d41f62aaa)

libstdc++: Micro-optimization for std::optional [PR112480]

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 2c492f99fc1fcb5f598286c3f3a21a05bca69d9e)

libstdc++: Add static_assert to std::integer_sequence [PR112473]

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 0953497a81f1e320989b9f2aaa7f56747eddd4a0)

libstdc++: Disable std::formatter::set_debug_format [PR112832]

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 3cd73543a1122d3c81409e3e9a26c3e94c3d324f)

libstdc++: Use strerror_r in std::generic_category()::message(int) [PR110133]

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 51f94778b45514992a716b0b2d7a87244e6f0018)

Daily bump.

i386: Fix -fcf-protection -Os ICE due to movabsq peephole2 [PR112845]

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 e0786ca9a18c50ad08c40936b228e325193664b8)

i386: Fix rtl checking ICE in ix86_elim_entry_set_got [PR112837]

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 4586d7d0a92e9b60d0c01043e0ae262b1e06f337)

i386: Fix up signbit<mode>2 expander [PR112816]

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 994d6dc64435d6b7c50accca9941ee7decd92a22)