When long double is wider than double, but from_chars is implemented
in terms of double, tests that involve the full precision of long
double are expected to fail.  Mark them as such on aarch64-*-vxworks.


for  libstdc++-v3/ChangeLog

	* testsuite/20_util/from_chars/4.cc: Skip long double test06
	on aarch64-vxworks.
	* testsuite/20_util/to_chars/long_double.cc: Xfail run on
	aarch64-vxworks.

(cherry picked from commit e383fc69)

libstdc++-v3/ChangeLog:

	* doc/xml/manual/abi.xml (abi.versioning.history): Document
	libstdc++.so.6.0.32 and GLIBCXX_3.4.32 version.
	* doc/html/manual/abi.html: Regenerate.

(cherry picked from commit 2eadfb5c)

GCC_11.0 is an aarch64-specific outlier.

libstdc++-v3/ChangeLog:

	* doc/xml/manual/abi.xml (abi.versioning.history): Add
	GCC_7.0.0, GCC_9.0.0, GCC_11.0, GCC_12.0.0, GCC_13.0.0 for
	libgcc_s.

(cherry picked from commit 9cb3f254)

The following adds a testcase for PR109724 which was caused by
backporting r13-2375-gbe1b42de9c151d and fixed by r11-199-g2b42509f8b7bdf.

	PR tree-optimization/109724
	* g++.dg/torture/pr109724.C: New testcase.

(cherry picked from commit ee99aaae)

The following testcase ICEs because STV replaces there
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
     (nil))
with
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1
     (nil))
which is invalid because of the mode mismatch.
STV has fix_debug_reg_uses function which is supposed to fix this up
and adjust such debug insns into
(debug_insn 114 47 51 8 (var_location:TI D#3 (subreg:TI (reg:V1TI 91 [ p ]) 0)) -1
     (nil))
but it doesn't trigger here.
The IL before stv1 has:
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
     (nil))
...
(insn 63 62 64 8 (set (mem/c:TI (reg/f:DI 89 [ .result_ptr ]) [0 <retval>.mStorage+0 S16 A32])
        (reg:TI 91 [ p ])) "pr109676.C":4:48 87 {*movti_internal}
     (expr_list:REG_DEAD (reg:TI 91 [ p ])
        (nil)))
in bb 8 and
(insn 97 96 98 9 (set (reg:TI 91 [ p ])
        (mem/c:TI (plus:DI (reg/f:DI 19 frame)
                (const_int -32 [0xffffffffffffffe0])) [0 p+0 S16 A128])) "pr109676.C":26:12 87 {*movti_internal}
     (nil))
(insn 98 97 99 9 (set (mem/c:TI (plus:DI (reg/f:DI 19 frame)
                (const_int -64 [0xffffffffffffffc0])) [0 tmp+0 S16 A128])
        (reg:TI 91 [ p ])) "pr109676.C":26:12 87 {*movti_internal}
     (nil))
in bb9.
PUT_MODE on a REG is done in two spots in timode_scalar_chain::convert_insn,
one is:
  switch (GET_CODE (dst))
    {
    case REG:
      if (GET_MODE (dst) == TImode)
        {
          PUT_MODE (dst, V1TImode);
          fix_debug_reg_uses (dst);
        }
      if (GET_MODE (dst) == V1TImode)
when seeing the REG in SET_DEST and another one the hunk the patch adjusts.
Because bb 8 comes first in the order the pass walks the bbs, we first
notice the TImode pseudo on insn 63 where it is SET_SRC, use PUT_MODE there
unconditionally, so for a shared REG it changes all other uses in the IL,
and then don't call fix_debug_reg_uses because DF_REG_DEF_CHAIN (REGNO (src))
is non-NULL - the REG is set in insn 97 but we haven't processed it yet.
Later on we process insn 97, but because the REG in SET_DEST already has
V1TImode, we don't do anything, even when the src handling code earlier
relied on it being done.

The following patch fixes this by using similar code for both dst and src,
in particular calling fix_debug_reg_uses once when we actually change REG
mode from TImode to V1TImode, and not later on.

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

	PR debug/109676
	* config/i386/i386-features.cc (timode_scalar_chain::convert_insn):
	If src is REG, change its mode to V1TImode and call fix_debug_reg_uses
	for it only if it still has TImode.  Don't decide whether to call
	fix_debug_reg_uses based on whether SRC is ever set or not.

	* g++.target/i386/pr109676.C: New test.

(cherry picked from commit 3a715d3e)

This is an ABI problem on powerpc64le-linux, introduced in 13.1.
When libstdc++ is configured against old glibc, the
_ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_formati@@GLIBCXX_3.4.31
symbols are exported from the library, while when it is configured against
new enough glibc, those symbols aren't exported and we export instead
_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29
together with various other @@GLIBCXX_IEEE128_3.4.{29,30,31} and
@@CXXABI_IEEE128_1.3.13 symbols.  The idea was that those *IEEE128* symbol
versions (similarly to *LDBL* symbol versions) are optional (but if it
appears, all symbols from it up to the version of the library appears),
but the base appears always.
My _Float128 from_chars/to_chars changes unfortunately broke this.
I believe nothing really uses those symbols if libstdc++ has been
configured against old glibc, so if 13.1 wasn't already released, it might
be best to make sure they aren't exported on powerpc64le-linux.
But as they were exported, I think the best resolution for this ABI
difference is to add those 4 symbols as aliases to the
GLIBCXX_IEEE128_3.4.29 *u9__ieee128* symbols, which the following patch
does.

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

	* src/c++17/floating_from_chars.cc
	(_ZSt10from_charsPKcS0_RDF128_St12chars_format): New alias to
	_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format.
	* src/c++17/floating_to_chars.cc (_ZSt8to_charsPcS_DF128_): New alias to
	_ZSt8to_charsPcS_u9__ieee128.
	(_ZSt8to_charsPcS_DF128_St12chars_format): New alias to
	_ZSt8to_charsPcS_u9__ieee128St12chars_format.
	(_ZSt8to_charsPcS_DF128_St12chars_formati): New alias to
	_ZSt8to_charsPcS_u9__ieee128St12chars_formati.
	* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Updated.

(cherry picked from commit b51e2fd6)

As discussed on IRC, my _Float128/_Float64x support changes broke
abi.exp testing on powerpc64-linux.

The
_ZTIDF128_@@CXXABI_1.3.14
_ZTIDF64x@@CXXABI_1.3.14
_ZTIPDF128_@@CXXABI_1.3.14
_ZTIPDF64x@@CXXABI_1.3.14
_ZTIPKDF128_@@CXXABI_1.3.14
_ZTIPKDF64x@@CXXABI_1.3.14
symbols only appear on powerpc64le-linux (both when building against
very old glibcs as well as contemporary glibcs), while they don't
appear on powerpc64-linux, because the latter never has _Float128 or
_Float64x support.

But we were using the same baseline_symbols.txt file for both
powerpc64-linux and powerpc64le-linux, even when it contained quite a lot
of stuff specific to the latter; but that was just the IEEE128 related
stuff that appears only when configured against not very old glibc.

The following patch keeps those exports as is and just splits the
config/abi/post/ files, copies the current one to powerpc64le-linux
unmodified and removes the above mentioned symbols plus all
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbols
from the powerpc64-linux version.

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

	* configure.host (abi_baseline_pair): Use powerpc64le-linux-gnu
	rather than powerpc64-linux-gnu for powerpc64le*-linux*.
	* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Remove
	_ZTI*DF128_, _ZTI*DF64x symbols and symbols in
	GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbol
	versions.
	* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: New
	file.

(cherry picked from commit a13ea34c)

The following patch regenerates the ABI files (I've only changed the
Linux files which were updated recently (last month)).

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

	* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
	* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.

(cherry picked from commit 1d003da7)

I've followed what other files do, using attribute alias with not really
matching function type (after all, it isn't really possible when it is a
constructor), but seems I've missed it warns:
../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void std::ios_base_library_init()’ alias between functions of incompatible types ‘void()’ and ‘void
+(std::ios_base::Init::)()’ [-Wattribute-alias=]
  203 |   void ios_base_library_init (void)
      |        ^~~~~~~~~~~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++98/ios_init.cc:78:3: note: aliased declaration here
   78 |   ios_base::Init::Init()
      |   ^~~~~~~~
The PR talks about clang++ warning there (which I think isn't really
supported, libstdc++ sources ought to be built by GCC), but it warns
when built with GCC too.

The following patch fixes it by doing what other libstdc++ sources do in
those cases.

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

	PR libstdc++/109694
	* src/c++98/ios_init.cc: Add #pragma GCC diagnostic ignored for
	-Wattribute-alias.

(cherry picked from commit 87de39e4)

libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc 13.2+ libstdc++.so.6 [PR108969]

GCC used to emit an instance of an empty ios_base::Init class in
every TU which included <iostream> to ensure it is std::cout etc.
is initialized, but thanks to Patrick work on some targets (which have
init_priority attribute support) it is now initialized only inside of
libstdc++.so.6/libstdc++.a.

This causes a problem if people do something that has never been supported,
try to run GCC 13 compiled C++ code against GCC 12 or earlier
libstdc++.so.6 - std::cout etc. are then never initialized because code
including <iostream> expects the library to initialize it and the library
expects code including <iostream> to do that.

The following patch is second attempt to make this work cheaply as the
earlier attempt of aliasing the std::cout etc. symbols with another symbol
version didn't work out due to copy relocation breaking the aliases appart.

The patch forces just a _ZSt21ios_base_library_initv undefined symbol
into all *.o files which include <iostream> and while there is no runtime
relocation against that, it seems to enforce the right version of
libstdc++.so.6.  /home/jakub/src/gcc/obj08i/usr/local/ is the install
directory of trunk patched with this patch, /home/jakub/src/gcc/obj06/
is builddir of trunk without this patch, system g++ is GCC 12.1.1.
$ cat /tmp/hw.C
 #include <iostream>

int
main ()
{
  std::cout << "Hello, world!" << std::endl;
}
$ cd /home/jakub/src/gcc/obj08i/usr/local/bin
$ ./g++ -o /tmp/hw /tmp/hw.C
$ readelf -Wa /tmp/hw 2>/dev/null | grep initv
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4)
    71: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32
$ /tmp/hw
/tmp/hw: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw
/tmp/hw: /home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ g++ -o /tmp/hw /tmp/hw.C
$ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!

On sparc-sun-solaris2.11 one I've actually checked a version which had
defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but
init_priority attribute doesn't seem to be supported there and so I couldn't
actually test how this works there.  Using gas and Sun ld, Rainer, does one
need to use gas + gld for init_priority or something else?

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

	PR libstdc++/108969
	* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export
	_ZSt21ios_base_library_initv.
	* testsuite/util/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.32
	symver and make it the latestp.
	* src/c++98/ios_init.cc (ios_base_library_init): New alias.
	* acinclude.m4 (libtool_VERSION): Change to 6:32:0.
	* include/std/iostream: If init_priority attribute is supported
	and _GLIBCXX_SYMVER_GNU, force undefined _ZSt21ios_base_library_initv
	symbol into the object.
	* configure: Regenerated.

(cherry picked from commit 9a41d2cd)

`vr`, `vm` and `vd` constarint for vector register constarint, those 3
constarint has implemented on LLVM as well.

gcc/ChangeLog:

	* doc/md.texi (RISC-V): Add vr, vm, vd constarint.

(cherry picked from commit e8511cbb)

count_occurrences will conly count same RTX (same code and same mode),
but what we want to track is the occurrence of a register, a register
might appeared in the insn with different mode or contain in SUBREG.

Testcase coming from Kito.

gcc/ChangeLog:

	PR target/109535
	* config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function.
	(pass_vsetvl::cleanup_insns): Fix bug.

gcc/testsuite/ChangeLog:

	PR target/109535
	* g++.target/riscv/rvv/base/pr109535.C: New test.
	* gcc.target/riscv/rvv/base/pr109535.c: New test.

Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
Co-authored-by: kito-cheng <kito.cheng@sifive.com>
(cherry picked from commit a2d12abe)

This patch was just a cleanup after the actual bugfix, so let's revert it on
the branch.

	PR c++/109649

This reverts commit e9d2adc1.

This always sets _M_string_length in the constructor for ranges of input
iterators, such as stream iterators.

We copy from the source range to the local buffer, and then repeatedly
reallocate a larger one if necessary. When disposing the old buffer,
_M_is_local() is used to tell if the buffer is the local one or not (and
so must be deallocated). In addition to comparing the buffer address
with the local buffer, _M_is_local() has an optimization hint so that
the compiler knows that for a string using the local buffer, there is an
invariant that _M_string_length <= _S_local_capacity (added for PR109299
via r13-6915-gbf78b43873b0b7).  But we failed to set _M_string_length in
the constructor taking a pair of iterators, so the invariant might not
hold, and __builtin_unreachable() is reached. This causes UBsan errors,
and potentially misoptimization.

To ensure the invariant holds, _M_string_length is initialized to zero
before doing anything else, so that _M_is_local() doesn't see an
uninitialized value.

This issue only surfaces when constructing a string with a range of
input iterator, and the uninitialized _M_string_length happens to be
greater than _S_local_capacity, i.e., 15 for the std::string
specialization.

libstdc++-v3/ChangeLog:

	PR libstdc++/109703
	* include/bits/basic_string.h (basic_string(Iter, Iter, Alloc)):
	Initialize _M_string_length.

Signed-off-by: Kefu Chai <kefu.chai@scylladb.com>
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit cbf6c7a1)

During patch backporting, I've noticed that while most cp_walk_tree calls
with cp_fold_r callback callers were changed from &pset to cp_fold_data
&data, the VEC_INIT_EXPR gimplifications has not, so it still passes just
address of a hash_set<tree> and so if during the folding we ever touch
data->flags, we use uninitialized data there.

The following patch changes it to do the same thing as cp_fold_function
because the VEC_INIT_EXPR gimplifications will happen on function bodies
only.

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

	* cp-gimplify.cc (cp_fold_data): Move definition earlier.
	(cp_gimplify_expr): Pass address of ff_genericize | ff_mce_false
	constructed data rather than &pset to cp_walk_tree with cp_fold_r.

(cherry picked from commit 8d193b12)

The earlier commit wasn't fixing a known bug, so let's revert it on the
branch.

	PR c++/109678

This reverts commit 1189c038.

Here it turns out I also needed to adjust cfun when stepping out of the
member function to instantiate the DMI.  But instead of adding that tweak,
let's unify with instantiate_body and just push_to_top_level instead of
trying to do the minimum subset of it.  There was no measurable change in
compile time on stdc++.h.

This should also resolve 109506 without yet another tweak.

	PR c++/109666

gcc/cp/ChangeLog:

	* name-lookup.cc (maybe_push_to_top_level)
	(maybe_pop_from_top_level): Split out...
	* pt.cc (instantiate_body): ...from here.
	* init.cc (maybe_instantiate_nsdmi_init): Use them.
	* name-lookup.h: Declare them..

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/nsdmi-array2.C: New test.

In the comments for PR108099 Jakub provided some testcases that demonstrated
that even before the regression noted in the patch we were getting the
semantics of this extension wrong: in the unsigned case we weren't producing
the corresponding standard unsigned type but another distinct one of the
same size, and in the signed case we were just dropping it on the floor and
not actually returning a signed type at all.

The former issue is fixed by using c_common_signed_or_unsigned_type instead
of unsigned_type_for, and the latter issue by adding a (signed_p &&
typedef_decl) case.

This patch introduces a failure on std/ranges/iota/max_size_type.cc due to
the latter issue, since the testcase expects 'signed rep_t' to do something
sensible, and previously we didn't.  Now that we do, it exposes a bug in the
__max_diff_type::operator>>= handling of sign extension: when we evaluate
-1000 >> 2 in __max_diff_type we keep the MSB set, but leave the
second-most-significant bit cleared.

	PR c++/108099

gcc/cp/ChangeLog:

	* decl.cc (grokdeclarator): Don't clear typedef_decl after 'unsigned
	typedef' pedwarn.  Use c_common_signed_or_unsigned_type.  Also
	handle 'signed typedef'.

gcc/testsuite/ChangeLog:

	* g++.dg/ext/int128-8.C: New test.
	* g++.dg/ext/unsigned-typedef2.C: New test.
	* g++.dg/ext/unsigned-typedef3.C: New test.

Sadly, -Wdangling-reference generates false positives for std::span-like
user classes, and it seems imprudent to attempt to improve the heuristic
in GCC 13.  Let's move the warning to -Wextra, that will hopefully
reduce the number of false positives the users have been seeing with 13.

I'm leaving the warning in -Wall in 14 where I think I can write code
to detect std::span-like classes.

	PR c++/109642
	PR c++/109640
	PR c++/109671

gcc/c-family/ChangeLog:

	* c.opt (Wdangling-reference): Move from -Wall to -Wextra.

gcc/ChangeLog:

	* doc/invoke.texi: Document that -Wdangling-reference is
	enabled by -Wextra.

RISC-V will emit ".option nopic" when -fno-pie is in effect, which
matches the generic pattern. Just like done for Alpha, special-case
RISC-V.

gcc/testsuite/

	* c-c++-common/patchable_function_entry-decl.c: Special-case
	RISC-V.
	* c-c++-common/patchable_function_entry-default.c: Likewise.
	* c-c++-common/patchable_function_entry-definition.c: Likewise.

This patch fixes sign bit propagation when right-shifting a negative
__max_diff_type value by more than one, a bug that our existing test
coverage didn't expose until r14-159-g03cebd304955a6 fixed the front
end's 'signed typedef-name' handling that the test relies on (which is
a non-standard extension to the language grammar).

libstdc++-v3/ChangeLog:

	* include/bits/max_size_type.h (__max_diff_type::operator>>=):
	Fix propagation of sign bit.
	* testsuite/std/ranges/iota/max_size_type.cc: Avoid using the
	non-standard 'signed typedef-name'.  Add some compile-time tests
	for right-shifting a negative __max_diff_type value by more than
	one.

(cherry picked from commit 83470a5c)

Add @headerfile and @since tags. Add gamma_distribution to the correct
group (poisson distributions). Add a group for the sampling
distributions and add the missing definitions of their probability
functions. Add uniform_int_distribution back to the uniform
distributions group.

libstdc++-v3/ChangeLog:

	* include/bits/random.h (gamma_distribution): Add to the right
	doxygen group.
	(discrete_distribution, piecewise_constant_distribution)
	(piecewise_linear_distribution): Create a new doxygen group and
	fix the incomplete doxygen comments.
	* include/bits/uniform_int_dist.h (uniform_int_distribution):
	Add to doxygen group.

(cherry picked from commit d711f8f8)

libstdc++-v3/ChangeLog:

	* include/bits/uses_allocator.h: Add missing @file comment.
	* include/bits/regex.tcc: Remove stray doxygen comments.
	* include/experimental/memory_resource: Likewise.
	* include/std/bit: Tweak doxygen @cond comments.
	* include/std/expected: Likewise.
	* include/std/numbers: Likewise.

(cherry picked from commit 30f6aace)

This avoids showing absolute paths from the expansion of
@srcdir@/libsupc++/ in the doxygen File List view.

libstdc++-v3/ChangeLog:

	* doc/doxygen/user.cfg.in (STRIP_FROM_PATH): Remove prefixes
	from header paths.

(cherry picked from commit 975e8e83)

There's no good reason to conditionally close and reopen namespace std
within an #if block. Just include the <type_traits> header at the top
instead.

libstdc++-v3/ChangeLog:

	* include/bits/move.h: Simplify opening/closing namespace std.

(cherry picked from commit 5c8b154c)

libstdc++-v3/ChangeLog:

	* include/bits/memory_resource.h: Improve doxygen comments.
	* include/std/memory_resource: Likewise.

(cherry picked from commit afcf2b09)

libstdc++-v3/ChangeLog:

	PR libstdc++/40380
	* include/bits/basic_string.h: Improve doxygen comments.
	* include/bits/cow_string.h: Likewise.
	* include/bits/forward_list.h: Likewise.
	* include/bits/fs_dir.h: Likewise.
	* include/bits/fs_path.h: Likewise.
	* include/bits/quoted_string.h: Likewise.
	* include/bits/stl_bvector.h: Likewise.
	* include/bits/stl_map.h: Likewise.
	* include/bits/stl_multimap.h: Likewise.
	* include/bits/stl_multiset.h: Likewise.
	* include/bits/stl_set.h: Likewise.
	* include/bits/stl_vector.h: Likewise.
	* include/bits/unordered_map.h: Likewise.
	* include/bits/unordered_set.h: Likewise.
	* include/std/filesystem: Likewise.
	* include/std/iomanip: Likewise.

(cherry picked from commit 865869dc)

The vec_fmsubadd instuction actually had add twice, by mistake.

Also improve code-gen for all the complex patterns by using properly
undefined values.  Mostly this just prevents the compiler reserving space
in the stack frame.

gcc/ChangeLog:

	* config/gcn/gcn-valu.md (cmul<conj_op><mode>3): Use gcn_gen_undef.
	(cml<addsub_as><mode>4): Likewise.
	(vec_addsub<mode>3): Likewise.
	(cadd<rot><mode>3): Likewise.
	(vec_fmaddsub<mode>4): Likewise.
	(vec_fmsubadd<mode>4): Likewise, and use sub for the odd lanes.

(cherry picked from commit b17c57b0)

	* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po,
	ja.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po,
	zh_TW.po: Update.

libstdc++-v3/ChangeLog:

	* include/bits/mofunc_impl.h: Fix typo in doxygen comment.
	* include/std/format: Likewise.

(cherry picked from commit 481281cc)

Including the header source code in the doxygen-generated PDF file makes
it too large, and causes pdflatex to run out of memory. If we only set
SOURCE_BROWSER=YES for the HTML docs then we won't include the sources
in the PDF file.

There are several macros defined for std::valarray that are only used to
generate repetitive code and then #undef'd. Those aren't useful in the
doxygen docs, especially the ones that reuse the same name in different
files. Omitting them avoids warnings about duplicate labels in the
refman.tex file.

libstdc++-v3/ChangeLog:

	* doc/doxygen/user.cfg.in (SOURCE_BROWSER): Only set to YES for
	HTML docs.
	* include/bits/gslice_array.h (_DEFINE_VALARRAY_OPERATOR): Omit
	from doxygen docs.
	* include/bits/indirect_array.h (_DEFINE_VALARRAY_OPERATOR):
	Likewise.
	* include/bits/mask_array.h (_DEFINE_VALARRAY_OPERATOR):
	Likewise.
	* include/bits/slice_array.h (_DEFINE_VALARRAY_OPERATOR):
	Likewise.
	* include/std/valarray (_DEFINE_VALARRAY_UNARY_OPERATOR)
	(_DEFINE_VALARRAY_AUGMENTED_ASSIGNMENT)
	(_DEFINE_VALARRAY_EXPR_AUGMENTED_ASSIGNMENT)
	(_DEFINE_BINARY_OPERATOR): Likewise.

(cherry picked from commit afa69618)

On the following testcase we ICE, because after we emit the
variable-sized object may not be initialized except with an empty initializer
error we don't really reset the initializer to error_mark_node and then at
-Wformat checking time we ICE on seeing STRING_CST initializer for a VLA.

The following patch just arranges for error_mark_node to be returned after
the error diagnostics.

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

	PR c/109409
	* c-parser.cc (c_parser_initializer): Move diagnostics about
	initialization of variable sized object with non-empty initializer
	after c_parser_expr_no_commas call and ret.set_error (); after it.

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

(cherry picked from commit d8842271)