PR target/122695

gcc/

	* config/loongarch/loongarch.cc (loongarch_expand_vec_perm_1):
	Simplify and fix the logic preventing the xvshuf.* unpredictable
	behavior.

gcc/testsuite/

	* gcc.target/loongarch/pr122695-1.c: New test.
	* gcc.target/loongarch/pr122695-2.c: New test.

(cherry picked from commit f168d62bc552176572832bf129c9b392aeff46ad)

On i686, offsets into object archives could be 64-bit, but they're
inconsistently treated across the lto, which may sometimes result in
truncation of those offsets for large archives.

Use int64_t/off_t consistently across all uses of archive offsets to
make sure that they're always read and mapped correctly.

gcc/lto/ChangeLog

	PR lto/122515
	* lto.h (lto_section_slot): Set type of START to off_t.
	* lto-common.cc (lto_read_section_data): Adjust.
	* lto-object.cc (lto_obj_file_open): Set type of OFFSET to
	int64_t.

gcc/ChangeLog

	PR lto/122515
	* lto-wrapper.cc (debug_objcopy): Set type of INOFF to int64_t.
	(run_gcc): Set type of FILE_OFFSET to int64_t.

gcc/testsuite/ChangeLog

	PR lto/122515
	* lib/lto.exp (lto-build-archive): New procedure.
	(lto-execute-1): Use it.
	(lto-link-and-maybe-run, lto-get-options-main): Handle ar-link.
	* gcc.dg/lto/pr122515_0.c: New test case.
	* gcc.dg/lto/pr122515_1.c: New file.
	* gcc.dg/lto/pr122515_2.c: Likewise.
	* gcc.dg/lto/pr122515_3.c: Likewise.
	* gcc.dg/lto/pr122515_4.c: Likewise.
	* gcc.dg/lto/pr122515_5.c: Likewise.
	* gcc.dg/lto/pr122515_6.c: Likewise.
	* gcc.dg/lto/pr122515_7.c: Likewise.
	* gcc.dg/lto/pr122515_8.c: Likewise.
	* gcc.dg/lto/pr122515_9.c: Likewise.

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

Use the __last_system_error() function and the system_category to
convert the Windows error to a generic one.

libstdc++-v3/ChangeLog:

	PR libstdc++/122726
	* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
	(rename): Use __last_system_error to set errno accurately.
	* testsuite/27_io/filesystem/operations/rename.cc: Test
	error_code matches errc::no_such_file_or_directory.

(cherry picked from commit 77278e0292cd23f0d1ddbb5e6e18064e119bdd6f)

For

SUBROUTINE a( j, b, c, d )
  !GCC$ ATTRIBUTES noinline :: a
  COMPLEX*16         b
  COMPLEX*16         c( * ), d( * )
  DO k = 1, j
     c( k ) = - b * CONJG( d( k ) )
  END DO
END

we incorrectly generate .IFN_COMPLEX_MUL instead of .IFN_COMPLEX_MUL_CONJ.

The issue happens because in the call to vect_validate_multiplication the
operand vectors are passed by reference and so the stripping of the NEGATE_EXPR
after matching modifies the input vector.  If validation fail we flip the
operands and try again.  But we've already stipped the negates and so if we
match we would match a normal multiply.

This fixes the API by marking the operands as const and instead pass an explicit
output vec that's to be used.  This also reduces the number of copies we were
doing.

With this we now correctly detect .IFN_COMPLEX_MUL_CONJ.  Weirdly enough I
couldn't reproduce this with any C example because they get reassociated
differently and always succeed on the first attempt.  Fortran is easy to
trigger though so new fortran tests added.

gcc/ChangeLog:

	PR tree-optimization/122408
	* tree-vect-slp-patterns.cc (vect_validate_multiplication): Cleanup and
	document interface.
	(complex_mul_pattern::matches, complex_fms_pattern::matches): Update to
	new interface.

gcc/testsuite/ChangeLog:

	PR tree-optimization/122408
	* gfortran.target/aarch64/pr122408_1.f90: New test.
	* gfortran.target/aarch64/pr122408_2.f90: New test.

gcc/testsuite/ChangeLog:

	PR tree-optimization/122408
	* gfortran.target/aarch64/aarch64.exp: New test.