This was recently approved for C++26, but there's no harm in
implementing it unconditionally for C++20 and C++23. As it says in the
paper, it doesn't change the meaning of any valid code. It only enables
things that were previously ill-formed for questionable reasons.

libstdc++-v3/ChangeLog:

	* include/bits/iterator_concepts.h (projected): Replace class
	template with alias template denoting an ADL-proofed helper.
	(incremental_traits<projected<Iter, Proj>>): Remove.
	* testsuite/24_iterators/indirect_callable/projected-adl.cc:
	New test.

(cherry picked from commit 6eafdfc7)

When configured with --enable-cstdio=stdio_pure we need to consistently
use fseek and not mix seeks on the file descriptor with reads and writes
on the FILE stream.

There are also a number of bugs related to error handling and return
values, because fread and fwrite return 0 on error, not -1, and fseek
returns 0 on success, not the file offset.

libstdc++-v3/ChangeLog:

	PR libstdc++/110574
	* acinclude.m4 (GLIBCXX_CHECK_LFS): Check for fseeko and ftello
	and define _GLIBCXX_USE_FSEEKO_FTELLO.
	* config.h.in: Regenerate.
	* configure: Regenerate.
	* config/io/basic_file_stdio.cc (xwrite) [_GLIBCXX_USE_STDIO_PURE]:
	Check for fwrite error correctly.
	(__basic_file<char>::xsgetn) [_GLIBCXX_USE_STDIO_PURE]: Check for
	fread error correctly.
	(get_file_offset): New function.
	(__basic_file<char>::seekoff) [_GLIBCXX_USE_STDIO_PURE]: Use
	fseeko if available. Use get_file_offset instead of return value
	of fseek.
	(__basic_file<char>::showmanyc): Use get_file_offset.

(cherry picked from commit 2f6bbc9a)

The first parameter of fwrite should be the const char* __s which want
write to FILE *__file, rather than the FILE *__file write to the FILE
*__file.

libstdc++-v3/ChangeLog:

	* config/io/basic_file_stdio.cc (xwrite) [USE_STDIO_PURE]: Fix
	first argument.

(cherry picked from commit bb4f8f14)

These tests fail with -std=gnu++98/-D_GLIBCXX_DEBUG in the runtest
flags. They should require the c++11 effective target.

libstdc++-v3/ChangeLog:

	* testsuite/23_containers/forward_list/debug/iterator1_neg.cc:
	Skip as UNSUPPORTED for C++98 mode.
	* testsuite/23_containers/forward_list/debug/iterator3_neg.cc:
	Likewise.

(cherry picked from commit cd9964b7)

The <syncstream> header is only supported for the cxx11 ABI. The
declarations of basic_syncbuf, basic_osyncstream, syncbuf and
osyncstream were already correctly guarded by a check for
_GLIBCXX_USE_CXX11_ABI, but the wsyncbuf and wosyncstream declarations
were not.

libstdc++-v3/ChangeLog:

	* testsuite/27_io/headers/iosfwd/synopsis.cc: Make wsyncbuf and
	wosyncstream depend on _GLIBCXX_USE_CXX11_ABI.

(cherry picked from commit f9f05e48)

Building libstdc++ reportedly fails for targets without lock-free
std::atomic<T*> which don't define __GTHREAD_MUTEX_INIT:

src/c++20/tzdb.cc:110:21: error: 'constinit' variable 'std::chrono::{anonymous}::list_mutex' does not have a constant initializer
src/c++20/tzdb.cc:110:21: error: call to non-'constexpr' function 'std::mutex::mutex()'

The solution implemented by this commit is to use a local static mutex
when it can't be constinit, so that it's constructed on first use.

With this change, we can also simplify the preprocessor logic for
defining USE_ATOMIC_SHARED_PTR. It now depends on the same conditions as
USE_ATOMIC_LIST_HEAD, so in theory we could have a single macro. Keeping
them separate would allow us to replace the use of atomic<shared_ptr<T>>
with a mutex if that performs better, without having to give up on the
lock-free cache for fast access to the list head.

libstdc++-v3/ChangeLog:

	* src/c++20/tzdb.cc (USE_ATOMIC_SHARED_PTR): Define consistently
	with USE_ATOMIC_LIST_HEAD.
	(list_mutex): Replace global object with function. Use local
	static object when std::mutex constructor isn't constexpr.

(cherry picked from commit 5dfdf0ae)

These calls should be qualified to prevent ADL, which can cause errors
for incomplete types that are associated classes.

libstdc++-v3/ChangeLog:

	* include/bits/alloc_traits.h (_Destroy): Qualify call.
	* include/bits/stl_construct.h (_Destroy, _Destroy_n): Likewise.
	* testsuite/23_containers/vector/cons/destroy-adl.cc: New test.

(cherry picked from commit 33245d6b)

These functions should be qualified to disable unwanted ADL.

The overload of __check_singular_aux for safe iterators was previously
being found by ADL, because it wasn't declared before __check_singular.
Add a declaration so that it can be found by qualified lookup.

libstdc++-v3/ChangeLog:

	* include/debug/helper_functions.h (__get_distance)
	(__check_singular, __valid_range_aux, __valid_range): Qualify
	calls to disable ADL.
	(__check_singular_aux(const _Safe_iterator_base*)): Declare
	overload that was previously found via ADL.

(cherry picked from commit fa98bc42)

This fixes a crash when mangling an ADL-enabled call to a template-id
naming an unknown template (as per P0846R0).

	PR c++/110524

gcc/cp/ChangeLog:

	* mangle.cc (write_expression): Handle TEMPLATE_ID_EXPR
	whose template is already an IDENTIFIER_NODE.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/fn-template26.C: New test.

(cherry picked from commit 97ceaa11)

The matching code lacked a check that we end up with a PHI node
in the loop header.  This caused us to match a random PHI argument
now catched by the extra PHI_ARG_DEF_FROM_EDGE checking.

	PR tree-optimization/110669
	* tree-scalar-evolution.cc (analyze_and_compute_bitop_with_inv_effect):
	Check we matched a header PHI.

	* gcc.dg/torture/pr110669.c: New testcase.

cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
that it equals 8 elements of HImodeby setting REG_EQUAL note:

(insn 21 19 22 4 (set (reg:V4QI 98)
        (mem/u/c:V4QI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0  S4 A32])) "pr110206.c":12:42 1530 {*movv4qi_internal}
     (expr_list:REG_EQUAL (const_vector:V4QI [
                (const_int -52 [0xffffffffffffffcc]) repeated x4
            ])
        (nil)))
(insn 22 21 23 4 (set (reg:V8HI 100)
        (zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
                (parallel [
                        (const_int 0 [0])
                        (const_int 1 [0x1])
                        (const_int 2 [0x2])
                        (const_int 3 [0x3])
                        (const_int 4 [0x4])
                        (const_int 5 [0x5])
                        (const_int 6 [0x6])
                        (const_int 7 [0x7])
                    ])))) "pr110206.c":12:42 7471 {sse4_1_zero_extendv8qiv8hi2}
     (expr_list:REG_EQUAL (const_vector:V8HI [
                (const_int 204 [0xcc]) repeated x8
            ])
        (expr_list:REG_DEAD (reg:V4QI 98)
            (nil))))

We rely on the "undefined" vals to have a specific value (from the earlier
REG_EQUAL note) but actual code generation doesn't ensure this (it doesn't
need to).  That said, the issue isn't the constant folding per-se but that
we do not actually constant fold but register an equality that doesn't hold.

	PR target/110206

gcc/ChangeLog:

	* fwprop.cc (contains_paradoxical_subreg_p): Move to ...
	* rtlanal.cc (contains_paradoxical_subreg_p): ... here.
	* rtlanal.h (contains_paradoxical_subreg_p): Add prototype.
	* cprop.cc (try_replace_reg): Do not set REG_EQUAL note
	when the original source contains a paradoxical subreg.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/pr110206.c: New test.

(cherry picked from commit 1815e313)

gcc/fortran/ChangeLog:

	PR fortran/110288
	* symbol.cc (gfc_copy_formal_args_intr): When deriving the formal
	argument attributes from the actual ones for intrinsic procedure
	calls, take special care of CHARACTER arguments that we do not
	wrongly treat them formally as deferred-length.

gcc/testsuite/ChangeLog:

	PR fortran/110288
	* gfortran.dg/findloc_10.f90: New test.

(cherry picked from commit 3b2c523a)

gcc/ChangeLog:

	PR target/101469
	* config/sh/sh.md (peephole2): Handle case where eliminated reg
	is also	used by the address of the following memory operand.

	PR target/106966

gcc/ChangeLog:

	* config/alpha/alpha.cc (alpha_emit_set_long_const):
	Always use DImode when constructing long const.

gcc/testsuite/ChangeLog:

	* gcc.target/alpha/pr106966.c: New test.

(cherry picked from commit 337649c1)

The testcase added for this bug only checks conversion from wide strings
on construction, but the fix also covered conversion to wide strings via
path::wstring(). Add checks for that, and u16string() and u32string().

libstdc++-v3/ChangeLog:

	PR libstdc++/95048
	* testsuite/27_io/filesystem/path/construct/95048.cc: Check
	conversions to wide strings.
	* testsuite/experimental/filesystem/path/construct/95048.cc:
	Likewise.

(cherry picked from commit d6384ad1)

gcc/ChangeLog:

	* common/config/i386/cpuinfo.h
	(get_intel_cpu): Handle Granite Rapids D.
	* common/config/i386/i386-common.cc:
	(processor_alias_table): Add graniterapids-d.
	* common/config/i386/i386-cpuinfo.h
	(enum processor_subtypes): Add INTEL_COREI7_GRANITERAPIDS_D.
	* config.gcc: Add -march=graniterapids-d.
	* config/i386/driver-i386.cc (host_detect_local_cpu):
	Handle graniterapids-d.
	* config/i386/i386.h: (PTA_GRANITERAPIDS_D): New.
	* doc/extend.texi: Add graniterapids-d.
	* doc/invoke.texi: Ditto.

gcc/testsuite/ChangeLog:

	* g++.target/i386/mv16.C: Add graniterapids-d.
	* gcc.target/i386/funcspec-56.inc: Handle new march.

It turns out that adaint.c includes other Windows header files than just
windows.h, so defining WIN32_LEAN_AND_MEAN is not sufficient for it.

gcc/ada/

	* adaint.c [_WIN32]: Undefine 'abort' macro.

On ports with 32-bit long, the test produced excess errors:

    gcc/testsuite/g++.dg/vect/pr110557.cc:12:8: warning: width of
    'Item::y' exceeds its type

Reported-by: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>

gcc/testsuite/ChangeLog:

	* g++.dg/vect/pr110557.cc: Use long long instead of long for
	64-bit type.
	(test): Remove an unnecessary cast.

(cherry picked from commit 31283965)

If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended.  But this was not handled
correctly.

For example:

    int x : 8;
    long y : 55;
    bool z : 1;

The vectorized extraction of y was:

    vect__ifc__49.29_110 =
      MEM <vector(2) long unsigned int> [(struct Item *)vectp_a.27_108];
    vect_patt_38.30_112 =
      vect__ifc__49.29_110 & { 9223372036854775552, 9223372036854775552 };
    vect_patt_39.31_113 = vect_patt_38.30_112 >> 8;
    vect_patt_40.32_114 =
      VIEW_CONVERT_EXPR<vector(2) long int>(vect_patt_39.31_113);

This is obviously incorrect.  This pach has implemented it as:

    vect__ifc__25.16_62 =
      MEM <vector(2) long unsigned int> [(struct Item *)vectp_a.14_60];
    vect_patt_31.17_63 =
      VIEW_CONVERT_EXPR<vector(2) long int>(vect__ifc__25.16_62);
    vect_patt_32.18_64 = vect_patt_31.17_63 << 1;
    vect_patt_33.19_65 = vect_patt_32.18_64 >> 9;

gcc/ChangeLog:

	PR tree-optimization/110557
	* tree-vect-patterns.cc (vect_recog_bitfield_ref_pattern):
	Ensure the output sign-extended if necessary.

gcc/testsuite/ChangeLog:

	PR tree-optimization/110557
	* g++.dg/vect/pr110557.cc: New test.

(cherry picked from commit 63ae6bc6)

gcc/fortran/ChangeLog:

	PR fortran/110585
	* arith.cc (gfc_compare_expr): Handle equality comparison of constant
	complex gfc_expr arguments.

gcc/testsuite/ChangeLog:

	PR fortran/110585
	* gfortran.dg/findloc_9.f90: New test.

(cherry picked from commit 7ac1581d)

gcc/ChangeLog:

	PR c++/110595
	* doc/invoke.texi (Warning Options): Fix typo.

Restrict the generating of CONST_DECLs for D manifest constants to just
scalars without pointers.  It shouldn't happen that a reference to a
manifest constant has not been expanded within a function body during
codegen, but it has been found to occur in older versions of the D
front-end (PR98277), so if the decl of a non-scalar constant is
requested, just return its initializer as an expression.

	PR d/108842

gcc/d/ChangeLog:

	* decl.cc (DeclVisitor::visit (VarDeclaration *)): Only emit scalar
	manifest constants.
	(get_symbol_decl): Don't generate CONST_DECL for non-scalar manifest
	constants.
	* imports.cc (ImportVisitor::visit (VarDeclaration *)): New method.

gcc/testsuite/ChangeLog:

	* gdc.dg/pr98277.d: Add more tests.
	* gdc.dg/pr108842.d: New test.

(cherry picked from commit f934c575)

The stmt comparison function for GIMPLE_ASSIGNs for tail merging
still looks like it deals with pre-tuples IL.  The following
attempts to fix this, not only comparing the first operand (sic!)
of stmts but all of them plus also compare the operation code.

	PR tree-optimization/110556
	* tree-ssa-tail-merge.cc (gimple_equal_p): Check
	assign code and all operands of non-stores.

	* gcc.dg/torture/pr110556.c: New testcase.

(cherry picked from commit 7b16686e)

In this PR we face the issue that LIM speculates a load when
hoisting it out of the loop (since it knows it cannot trap).
Unfortunately this exposes undefined behavior when the load
accesses memory with the wrong dynamic type.  This later
makes PRE use that representation instead of the original
which accesses the same memory location but using a different
dynamic type leading to a wrong disambiguation of that
original access against another and thus a wrong-code transform.

Fortunately there already is code in PRE dealing with a similar
situation for code hoisting but that left a small gap which
when fixed also fixes the wrong-code transform in this bug even
if it doesn't address the underlying issue of LIM speculating
that load.

The upside is this fix is trivially safe to backport and chances
of code generation regressions are very low.

	PR tree-optimization/110515
	* tree-ssa-pre.cc (compute_avail): Make code dealing
	with hoisting loads with different alias-sets more
	robust.

	* g++.dg/opt/pr110515.C: New testcase.

(cherry picked from commit 9f4f8334)

Feeding not optimized IL can result in predicate normalization
to simplify things so a predicate can get true or false.  The
following re-orders the early exit in that case to come after
simplification and normalization to take care of that.

	PR tree-optimization/110392
	* gimple-predicate-analysis.cc (uninit_analysis::is_use_guarded):
	Do early exits on true/false predicate only after normalization.

(cherry picked from commit ab6eac20)

The following fixes a bug that manifests itself during fold-left
reduction transform in picking not the last scalar def to replace
and thus double-counting some elements.  But the underlying issue
is that we merge a load permutation into the in-order reduction
which is of course wrong.

Now, reduction analysis has not yet been performend when optimizing
permutations so we have to resort to check that ourselves.

	PR tree-optimization/110381
	* tree-vect-slp.cc (vect_optimize_slp_pass::start_choosing_layouts):
	Materialize permutes before fold-left reductions.

	* gcc.dg/vect/pr110381.c: New testcase.

(cherry picked from commit 53d6f57c)

This patch fixes this issue happens on GCC-13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560

This patch should be backported to GCC-13.
GCC-14 has rewritten this function, so there is no issue.

gcc/ChangeLog:

	PR target/110560
	* config/riscv/riscv-vsetvl.cc (local_eliminate_vsetvl_insn): Fix bug.

Ensure that that container aggregate expressions are expanded as
such and not as records even if the type of the expression is a
record.

gcc/ada/

	* exp_aggr.adb (Expand_N_Aggregate): Ensure that container
	aggregate expressions do not get expanded as records but instead
	as container aggregates.

This just applies the same fix to Expand_Array_Aggregate as the one that was
recently applied to Convert_To_Assignments.

gcc/ada/

	* exp_aggr.adb (Convert_To_Assignments): Tweak comment.
	(Expand_Array_Aggregate): Do not delay the expansion if the parent
	node is a container aggregate.