With nvptx offloading configured, and supported, and CUDA available:

    $ make check-target-libgomp RUNTESTFLAGS="--all c.exp=context-1.c c++.exp=context-1.c"
    [...]
    Running [...]/libgomp.oacc-c/c.exp ...
    PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)
    PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  execution test
    PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  (test for excess errors)
    PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  execution test
    UNSUPPORTED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2
    Running [...]/libgomp.oacc-c++/c++.exp ...
    PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)
    PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  execution test
    PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  (test for excess errors)
    PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  execution test
    UNSUPPORTED: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2
    [...]

..., but for 'c++.exp=context-1.c' alone, we currently get all-UNSUPPORTED:

    $ make check-target-libgomp RUNTESTFLAGS_="--all c++.exp=context-1.c"
    [...]
    Running [...]/libgomp.oacc-c++/c++.exp ...
    UNSUPPORTED: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0
    UNSUPPORTED: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2
    UNSUPPORTED: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/context-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2
    [...]

That is, if 'c.exp' executes first, it does successfully evaluate
'dg-require-effective-target openacc_cublas' -- and does cache this result (so
it isn't reevaluated for 'c++.exp').  However, for 'c++.exp' alone (that is,
without the 'c.exp' result cached), we run into:

    spawn -ignore SIGHUP [xgcc] [...] -x c++ openacc_cublas2311907.c [...]
    In file included from /usr/include/cuda_fp16.h:3673,
                     from /usr/include/cublas_api.h:75,
                     from /usr/include/cublas_v2.h:65,
                     from openacc_cublas2311907.c:3:
    /usr/include/cuda_fp16.hpp:67:10: fatal error: utility: No such file or directory

We're missing include paths to C++/libstdc++ build-tree headers.

Fix this by using the mechanism introduced for Fortran in
r212268 (commit f707da16) re
"libgomp.fortran/fortran.exp - add -fintrinsic-modules-path ${blddir}".

	libgomp/
	* testsuite/libgomp.c++/c++.exp: Use 'lang_include_flags' instead
	of 'libstdcxx_includes'.
	* testsuite/libgomp.oacc-c++/c++.exp: Likewise.

(cherry picked from commit 1b93b919)

... given that plain 'autoreconf' achieves the same.

	libgm2/
	* autogen.sh: Remove.

(cherry picked from commit bd6dbdb1)

Specifying explicit '-I ..' before '-I ../config' is what (most) other GCC
components do.  Specifying '-I .' is not necessary.

With the order of '-I's aligned, 'autogen.sh' and plain 'autoreconf' then
produce identical results.

	libgm2/
	* autogen.sh: For 'aclocal', 'autoreconf', remove '-I .',
	add '-I ..'.
	* Makefile.am (ACLOCAL_AMFLAGS): Remove '-I .'.
	* libm2cor/Makefile.am (ACLOCAL_AMFLAGS): Likewise.
	* libm2iso/Makefile.am (ACLOCAL_AMFLAGS): Likewise.
	* libm2log/Makefile.am (ACLOCAL_AMFLAGS): Likewise.
	* libm2min/Makefile.am (ACLOCAL_AMFLAGS): Likewise.
	* libm2pim/Makefile.am (ACLOCAL_AMFLAGS): Likewise.
	* aclocal.m4: Regenerate.
	* Makefile.in: Likewise.
	* libm2cor/Makefile.in: Likewise.
	* libm2iso/Makefile.in: Likewise.
	* libm2log/Makefile.in: Likewise.
	* libm2min/Makefile.in: Likewise.
	* libm2pim/Makefile.in: Likewise.

(cherry picked from commit 8b8a4fb8)

This was noticed when fixing the gccgo usage of the macro, the
rust usage is very similar.

TARGET_AIX is defined as a non-zero value on linux/powerpc64le
which may cause unexpected behavior.  TARGET_AIX_OS should be
used to toggle AIX specific behavior.

2023-06-22  Paul E. Murphy  <murphyp@linux.ibm.com>

gcc/rust/
	* rust-object-export.cc [TARGET_AIX]: Rename and update usage to
	TARGET_AIX_OS.

(cherry picked from commit 8a30775b)

TARGET_AIX is defined to a non-zero value on linux and maybe other
powerpc64le targets.  This leads to unexpected behavior such as
dropping the .go_export section when linking a shared library
on linux/powerpc64le.

Instead, use TARGET_AIX_OS to toggle AIX specific behavior.

Fixes golang/go#60798.

2023-06-22  Paul E. Murphy  <murphyp@linux.ibm.com>

gcc/go/
	* go-backend.cc [TARGET_AIX]: Rename and update usage to TARGET_AIX_OS.
	* go-lang.cc: Likewise.

(cherry picked from commit b76cd1ec)

pass_insert_vzeroupper is under condition

TARGET_AVX && TARGET_VZEROUPPER
&& flag_expensive_optimizations && !optimize_size

But the document of mvzeroupper doesn't mention the insertion
required -O2 and above, it may confuse users when they explicitly
use -Os -mvzeroupper.

------------
mvzeroupper
Target Mask(VZEROUPPER) Save
Generate vzeroupper instruction before a transfer of control flow out of
the function.
------------

The patch moves flag_expensive_optimizations && !optimize_size to
ix86_option_override_internal. It makes -mvzeroupper independent of
optimization level, but still keeps the behavior of architecture
tuning(emit_vzeroupper) unchanged.

gcc/ChangeLog:

	* config/i386/i386-features.cc (pass_insert_vzeroupper:gate):
	Move flag_expensive_optimizations && !optimize_size to ..
	* config/i386/i386-options.cc (ix86_option_override_internal):
	.. this, it makes -mvzeroupper independent of optimization
	level, but still keeps the behavior of architecture
	tuning(emit_vzeroupper) unchanged.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/avx-vzeroupper-29.c: New testcase.
	* gcc.target/i386/avx-vzeroupper-12.c: Adjust testcase.
	* gcc.target/i386/avx-vzeroupper-7.c: Ditto.
	* gcc.target/i386/avx-vzeroupper-9.c: Ditto.

__bfloat16 is redefined from typedef short to real __bf16 since GCC
V13. The patch issues an warning for potential silent implicit
conversion between __bf16 and short where users may only expect a
data movement.

To avoid too many false positive, warning is only under
TARGET_AVX512BF16.

gcc/ChangeLog:

	* config/i386/i386.cc (ix86_invalid_conversion): New function.
	(TARGET_INVALID_CONVERSION): Define as
	ix86_invalid_conversion.

gcc/testsuite/ChangeLog:

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

The manual references asm goto as being implicitly volatile already
and that was done when asm goto could not have outputs. When outputs
were added to `asm goto`, only asm goto without outputs were still being
marked as volatile. Now some parts of GCC decide, removing the `asm goto`
is ok if the output is not used, though not updating the CFG (this happens
on both the RTL level and the gimple level). Since the biggest user of `asm goto`
is the Linux kernel and they expect them to be volatile (they use them to
copy to/from userspace), we should just mark the inline-asm as volatile.

OK? Bootstrapped and tested on x86_64-linux-gnu.

	PR middle-end/110420
	PR middle-end/103979
	PR middle-end/98619

gcc/ChangeLog:

	* gimplify.cc (gimplify_asm_expr): Mark asm with labels as volatile.

gcc/testsuite/ChangeLog:

	* gcc.c-torture/compile/asmgoto-6.c: New test.

(cherry picked from commit 478840a2)

In IPA-SRA we use can_be_local_p () predicate rather than just plain
local call graph flag in order to figure out whether the node is a
part of an external API that we cannot change.  Although there are
cases where this can allow more transformations, it also means we can
analyze functions which have no callers at all, which is pointless.

Moreover, it makes an assert of hint propagation trigger, which checks
that we have looked at callers before processing hints that come from
them.  This has been reported as PR 110276.

This patch simply adds a check that a node has at least one caller
into the early checks and makes the node a non-candidate for any
transformation if it does not.

gcc/ChangeLog:

2023-06-16  Martin Jambor  <mjambor@suse.cz>

	PR ipa/110276
	* ipa-sra.cc (struct caller_issues): New field there_is_one.
	(check_for_caller_issues): Set it.
	(check_all_callers_for_issues): Check it.

gcc/testsuite/ChangeLog:

2023-06-16  Martin Jambor  <mjambor@suse.cz>

	PR ipa/110276
	* gcc.dg/ipa/pr110276.c: New test.

(cherry picked from commit 8a665a8d3b45c947d5793e2c9c3df8a1c0302f03)

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

The testcase is too big and I failed to reduce it so I didn't append
test into this patch.

This patch should not only land into GCC-14 but also should backport to GCC-13.

	PR target/110264

gcc/ChangeLog:

	* config/riscv/riscv-vsetvl.cc (insert_vsetvl): Fix bug.

(cherry picked from commit dd6e1cba)

There is a missing space between the return type and the name
which causes the name not to be outputted in the html docs.

Committed as obvious after building html docs.

gcc/ChangeLog:

	* doc/extend.texi (__builtin_alloca_with_align_and_max): Fix
	defbuiltin usage.

(cherry picked from commit fb909bc1)

Since PR96435, both boolean objects and expressions have been evaluated
in the following way.

    (*(ubyte*)&obj_or_expr) & 1

It has been noted that sometimes this can cause the back-end to optimize
in non-obvious ways - in particular with __builtin_expect.

This @safe feature is now restricted to just when reading the value of a
bool field that comes from a union.

	PR d/110359

gcc/d/ChangeLog:

	* d-convert.cc (convert_for_rvalue): Only apply the @safe boolean
	conversion to boolean fields of a union.
	(convert_for_condition): Call convert_for_rvalue in the default case.

gcc/testsuite/ChangeLog:

	* gdc.dg/pr110359.d: New test.

(cherry picked from commit ab98db1e)

Backports patch from upstream dmd mainline for fixing PR110113.

The data being Mem.xrealloc'd contains many Array(T) fields, some of
which have self references in their data.ptr field thanks to the
smallarray optimization used by Array.

Naturally then, the memcpy from old GC data to new retains those self
referenced addresses, and the GC marks the old data as "free". Some time
later GC.malloc will return a pointer to said "free" data. So now we
have two GC references to the same memory. One that is treating the data
as an Array(VarDeclaration) in dmd.escape.escapeByStorage, and the other
as an AA in the symtab of a dmd.dsymbol.ScopeDsymbol.

Fix this memory corruption by not storing the data in a global variable
for reuse.  If there are no more live references, the GC will free it.

	PR d/110113

gcc/d/ChangeLog:

	* dmd/escape.d (checkMutableArguments): Always allocate new buffer for
	computing escapeBy.

gcc/testsuite/ChangeLog:

	* gdc.test/compilable/test23978.d: New test.

Reviewed-on: https://github.com/dlang/dmd/pull/15302

D front-end changes:

	- Import dmd v2.103.1.
	- Deprecated invalid special token sequences inside token strings.

D runtime changes:

	- Import druntime v2.103.1.

Phobos changes:

	- Import phobos v2.103.1.

gcc/d/ChangeLog:

	* dmd/MERGE: Merge upstream dmd a45f4e9f43.
	* dmd/VERSION: Bump version to v2.103.1.

libphobos/ChangeLog:

	* libdruntime/MERGE: Merge upstream druntime a45f4e9f43.
	* src/MERGE: Merge upstream phobos 106038f2e.

(cherry picked from commit 55620c7b)

In the Go 1.21 release the package internal/profile imports
internal/lazyregexp.  That works when bootstrapping with Go 1.17,
because that compiler has internal/lazyregep and permits importing it.
We also have internal/lazyregexp in libgo, but since it is not installed
it is not available for importing.  This CL adds internal/lazyregexp
to the list of internal packages that are installed for bootstrapping.

The Go 1.21, and earlier, releases have a couple of functions in
the internal/abi package that are always fully intrinsified.
The gofrontend recognizes and intrinsifies those functions as well.
However, the gofrontend was also building function descriptors
for references to the functions without calling them, which
failed because there was nothing to refer to.  That is OK for the
gc compiler, which guarantees that the functions are only called,
not referenced.  This CL arranges to not generate function descriptors
for these functions.

For golang/go#60913

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504798

The argument for is_xible changed from list to vec in GCC 14.

gcc/cp/ChangeLog:

	* call.cc (maybe_init_list_as_array): Build a list.

The maybe_init_list_as_range optimization is a form of copy elision, but we
can only elide well-formed copies.

	PR c++/110102

gcc/cp/ChangeLog:

	* call.cc (maybe_init_list_as_array): Check that the element type is
	copyable.

gcc/testsuite/ChangeLog:

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

In the testcase, the user wants the assignment to use the operator= declared
in the class, but because [over.match.list] says that explicit constructors
are also considered for list-initialization, as affirmed in CWG1228, we end
up choosing the implicitly-declared copy assignment operator, using the
explicit constructor template for the argument, which is ill-formed.  Other
implementations haven't implemented CWG1228, so we keep getting bug reports.

Discussion in CWG led to the idea for this targeted relaxation: if we use an
explicit constructor for the conversion to the argument of a copy or move
special member function, that makes the candidate worse than another.

	DR 2735
	PR c++/109247

gcc/cp/ChangeLog:

	* call.cc (sfk_copy_or_move): New.
	(joust): Add tiebreaker for explicit conv and copy ctor.

gcc/testsuite/ChangeLog:

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

When unrolling we eventually kill nb_iterations info since it may
refer to removed SSA names.  But we do this only after cleaning
up the CFG which in turn can end up accessing it.  Fixed by
swapping the two.

	PR tree-optimization/110298
	* tree-ssa-loop-ivcanon.cc (tree_unroll_loops_completely):
	Clear number of iterations info before cleaning up the CFG.

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

(cherry picked from commit 916add3b)

When we process a scope typedef during early debug creation and
we have already created a DIE for the type when the decl is
TYPE_DECL_IS_STUB and this DIE is still in limbo we end up
just re-parenting that type DIE instead of properly creating
a DIE for the decl, eventually picking up the now completed
type and creating DIEs for the members.  Instead this is currently
defered to the second time we come here, when we annotate the
DIEs with locations late where now the type DIE is no longer
in limbo and we fall through doing the job for the decl.

The following makes sure we perform the necessary early tasks
for this by continuing with the decl DIE creation after setting
a parent for the limbo type DIE.

	PR debug/110295
	* dwarf2out.cc (process_scope_var): Continue processing
	the decl after setting a parent in case the existing DIE
	was in limbo.

	* g++.dg/debug/pr110295.C: New testcase.

(cherry picked from commit 963f87f8)

The gimplifier can elide initialized constant automatic variables
to static storage in which case TARGET_EXPR gimplification needs
to avoid emitting a CLOBBER for them since their lifetime is no
longer limited.  Failing to do so causes spurious dangling-pointer
diagnostics on the added testcase for some targets.

	PR middle-end/110055
	* gimplify.cc (gimplify_target_expr): Do not emit
	CLOBBERs for variables which have static storage duration
	after gimplifying their initializers.

	* g++.dg/warn/Wdangling-pointer-pr110055.C: New testcase.

(cherry picked from commit 84eec291)

This improves the edge avoidance heuristic by re-ordering the
topological sort of the graph to make sure the component with
the ESCAPED node is processed first.  This improves the number
of created edges which directly correlates with the number
of bitmap_ior_into calls from 141447426 to 239596 and the
compile-time from 1083s to 3s.  It also improves the compile-time
for the related PR109143 from 81s to 27s.

I've modernized the topological sorting API on the way as well.

	PR ipa/109983
	PR tree-optimization/109143
	* tree-ssa-structalias.cc (struct topo_info): Remove.
	(init_topo_info): Likewise.
	(free_topo_info): Likewise.
	(compute_topo_order): Simplify API, put the component
	with ESCAPED last so it's processed first.
	(topo_visit): Adjust.
	(solve_graph): Likewise.

(cherry picked from commit 95e5c38a)

This patch refactors the ls64 builtins to allow the compiler to define them
directly instead of having wrapper functions in arm_acle.h. This should be not
only easier to maintain, but it makes two important correctness fixes:
 - It fixes PR110132, where the builtins ended up getting declared with
   invisible bindings in the C FE, so the FE ended up synthesizing
   incompatible implicit definitions for these builtins.
 - It allows the builtins to be used with LTO, which didn't work previously.

We also take the opportunity to add test coverage from C++ for these
builtins.

gcc/ChangeLog:

	PR target/110132
	* config/aarch64/aarch64-builtins.cc (aarch64_general_simulate_builtin):
	New. Use it ...
	(aarch64_init_ls64_builtins): ... here. Switch to declaring public ACLE
	names for builtins.
	(aarch64_general_init_builtins): Ensure we invoke the arm_acle.h
	setup if in_lto_p, just like we do for SVE.
	* config/aarch64/arm_acle.h: (__arm_ld64b): Delete.
	(__arm_st64b): Delete.
	(__arm_st64bv): Delete.
	(__arm_st64bv0): Delete.

gcc/testsuite/ChangeLog:

	PR target/110132
	* lib/target-supports.exp (check_effective_target_aarch64_asm_FUNC_ok):
	Extend to ls64.
	* g++.target/aarch64/acle/acle.exp: New.
	* g++.target/aarch64/acle/ls64.C: New test.
	* g++.target/aarch64/acle/ls64_lto.C: New test.
	* gcc.target/aarch64/acle/ls64_lto.c: New test.
	* gcc.target/aarch64/acle/pr110132.c: New test.

(cherry picked from commit 9963029a)

The st64b pattern incorrectly had an output constraint on the register
operand containing the destination address for the store, leading to
wrong code. This patch fixes that.

gcc/ChangeLog:

	PR target/110100
	* config/aarch64/aarch64-builtins.cc (aarch64_expand_builtin_ls64):
	Use input operand for the destination address.
	* config/aarch64/aarch64.md (st64b): Fix constraint on address
	operand.

gcc/testsuite/ChangeLog:

	PR target/110100
	* gcc.target/aarch64/acle/pr110100.c: New test.

(cherry picked from commit 737a0b74)

The ls64 builtin code was using incorrect GNU style with eight spaces where
there should be a tab. Fixed thusly.

gcc/ChangeLog:

	PR target/110100
	* config/aarch64/aarch64-builtins.cc (aarch64_init_ls64_builtins_types):
	Replace eight consecutive spaces with tabs.
	(aarch64_init_ls64_builtins): Likewise.
	(aarch64_expand_builtin_ls64): Likewise.
	* config/aarch64/aarch64.md (ld64b): Likewise.
	(st64b): Likewise.
	(st64bv): Likewise
	(st64bv0): Likewise.

(cherry picked from commit 71361354)

The final argument to mmap, of type off_t, varies.
In CL 445375 we changed it to always use the C off_t type,
but that broke 32-bit big-endian Linux systems.  On those systems,
using the C off_t type requires calling the mmap64 function.
In C this is automatically handled by the <sys/mman.h> file.
In Go, we would have to change the magic //extern comment to
call mmap64 when appropriate.  Rather than try to get that right,
we instead go through a C function that uses C implicit type
conversions to pick the right type.

Fixes PR go/110297

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504415

This patch is to make newly added test cases pr109932-{1,2}.c
check int128 effective target to avoid unsupported type error
on 32-bit.  I did hit this failure during testing and fixed
it, but made a stupid mistake not updating the local formatted
patch which was actually out of date.

	PR testsuite/110230
	PR target/109932

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/pr109932-1.c: Adjust with int128 effective target.
	* gcc.target/powerpc/pr109932-2.c: Ditto.

(cherry picked from commit 16eb9d69)

As PR109932 shows, builtins __builtin_{un,}pack_vector_int128
should be guarded under vsx rather than power7, as their
corresponding bif patterns have the conditions TARGET_VSX
and VECTOR_MEM_ALTIVEC_OR_VSX_P (V1TImode).  This patch is to
move __builtin_{un,}pack_vector_int128 to stanza vsx to ensure
their supports.

	PR target/109932

gcc/ChangeLog:

	* config/rs6000/rs6000-builtins.def (__builtin_pack_vector_int128,
	__builtin_unpack_vector_int128): Move from stanza power7 to vsx.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/pr109932-1.c: New test.
	* gcc.target/powerpc/pr109932-2.c: New test.

(cherry picked from commit ff83d1b4)

As PR110011 shows, when encoding 128 bits fp constant into
toc, we adopts REAL_VALUE_TO_TARGET_LONG_DOUBLE which is
to find the first float mode with LONG_DOUBLE_TYPE_SIZE
bits of precision, it would be TFmode here.  But the 128
bits fp constant can be with mode IFmode or KFmode, which
doesn't necessarily have the same underlying float format
as the one of TFmode, like this PR exposes, with option
-mabi=ibmlongdouble TFmode has ibm_extended_format while
KFmode has ieee_quad_format, mixing up the formats (the
encoding/decoding ways) would cause unexpected results.

This patch is to make it use constant's own mode instead
of TFmode for real_to_target call.

	PR target/110011

gcc/ChangeLog:

	* config/rs6000/rs6000.cc (output_toc): Use the mode of the 128-bit
	floating constant itself for real_to_target call.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/pr110011.c: New test.

(cherry picked from commit 388809f2)