In check_return_expr, we suppress the -Wdangling-reference warning when
we're sure it would be a false positive.  It wasn't working in a
template, though, because the suppress_warning call was never reached.

	PR c++/109774

gcc/cp/ChangeLog:

	* typeck.cc (check_return_expr): In a template, return only after
	suppressing -Wdangling-reference.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Wdangling-reference13.C: New test.

(cherry picked from commit f25d2de1)

RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.

This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be specified using the -minline-atomics and
-mno-inline-atomics command line flags.

gcc/libgcc/config/riscv/atomic.c has the same logic implemented in asm.
This will need to stay for backwards compatibility and the
-mno-inline-atomics flag.

2023-05-03 Patrick O'Neill <patrick@rivosinc.com>

gcc/ChangeLog:
	PR target/104338
	* config/riscv/riscv-protos.h: Add helper function stubs.
	* config/riscv/riscv.cc: Add helper functions for subword masking.
	* config/riscv/riscv.opt: Add command-line flags
	-minline-atomics and -mno-inline-atomics.
	* config/riscv/sync.md: Add masking logic and inline asm for
	fetch_and_op, fetch_and_nand, CAS, and exchange ops.
	* doc/invoke.texi: Add blurb regarding new command-line flags
	-minline-atomics and -mno-inline-atomics.

libgcc/ChangeLog:
	PR target/104338
	* config/riscv/atomic.c: Add reference to duplicate logic.

gcc/testsuite/ChangeLog:
	PR target/104338
	* gcc.target/riscv/inline-atomics-1.c: New test.
	* gcc.target/riscv/inline-atomics-2.c: New test.
	* gcc.target/riscv/inline-atomics-3.c: New test.
	* gcc.target/riscv/inline-atomics-4.c: New test.
	* gcc.target/riscv/inline-atomics-5.c: New test.
	* gcc.target/riscv/inline-atomics-6.c: New test.
	* gcc.target/riscv/inline-atomics-7.c: New test.
	* gcc.target/riscv/inline-atomics-8.c: New test.

Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

When offloading was enabled, top-level 'asm' were added to the offloading
section, confusing assemblers which did not support the syntax. Additionally,
with offloading and -flto, the top-level assembler code did not end up
in the host files.

As r14-321-g9a41d2cdbcd added top-level 'asm' to one libstdc++ header file,
the issue became more apparent, causing fails with nvptx for some
C++ testcases.

	PR libstdc++/109816

gcc/ChangeLog:

	* lto-cgraph.cc (output_symtab): Guard lto_output_toplevel_asms by
	'!lto_stream_offload_p'.

libgomp/ChangeLog:

	* testsuite/libgomp.c++/target-map-class-1.C: New test.
	* testsuite/libgomp.c++/target-map-class-2.C: New test.

(cherry picked from commit a835f046)

The non-atomic path does not have range information,
we have to adjust the assert handle that case, too.

libgcc/ChangeLog:
	* unwind-dw2-fde.c: Fix assert in non-atomic path.

The assertion in __deregister_frame_info_bases assumes that for every
frame something was inserted into the lookup data structure by
__register_frame_info_bases. Unfortunately, this does not necessarily
hold true as the btree_insert call in __register_frame_info_bases will
not insert anything for empty ranges. Therefore, we need to explicitly
account for such empty ranges in the assertion as `ob` will be a null
pointer for such ranges, hence causing the assertion to fail.

Signed-off-by: Sören Tempel <soeren@soeren-tempel.net>

libgcc/ChangeLog:
	* unwind-dw2-fde.c: Accept empty ranges when deregistering frames.

The following puts the dg-require-effective-target properly after
the dg-do.

	* gcc.dg/vect/pr108950.c: Re-order dg-require-effective-target
	and dg-do.

(cherry picked from commit 66e268eb)

I noticed only after the fact that the new testcase template/function2.C
(from r14-708-gc3afdb8ba8f183) is just a subset of ext/visibility/anon8.C,
so let's get rid of it.

	PR c++/83258

gcc/testsuite/ChangeLog:

	* g++.dg/ext/visibility/anon8.C: Mention PR83258.
	* g++.dg/template/function2.C: Removed.

(cherry picked from commit 10098788)

r13-2701-g7107ea6fb933f1 made us correctly accept during constexpr
evaluation 'mutable' member accesses of objects constructed during
that evaluation, while continuing to reject such accesses for constexpr
objects constructed outside of that evaluation, by considering the
CONSTRUCTOR_MUTABLE_POISON flag during cxx_eval_component_reference.

However, this flag is set only for the outermost CONSTRUCTOR of a
constexpr variable initializer, so if we're accessing a 'mutable' member
of a nested CONSTRUCTOR, the flag won't be set and we won't reject the
access.  This can lead to us accepting invalid code, as in the first
testcase, or even wrong code generation due to our speculative constexpr
evaluation, as in the second and third testcase.

This patch fixes this by setting CONSTRUCTOR_MUTABLE_POISON recursively
rather than only on the outermost CONSTRUCTOR.

	PR c++/109745

gcc/cp/ChangeLog:

	* typeck2.cc (poison_mutable_constructors): Define.
	(store_init_value): Use it instead of setting
	CONSTRUCTOR_MUTABLE_POISON directly.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/constexpr-mutable4.C: New test.
	* g++.dg/cpp0x/constexpr-mutable5.C: New test.
	* g++.dg/cpp1y/constexpr-mutable2.C: New test.

(cherry picked from commit 02777f20)

We accept this testcase since r13-806-g221acd67ca50f8.

	PR c++/103807

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/lambda-targ1.C: New test.

(cherry picked from commit 0d0c467d)

r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17 (which r9-3836-g4be5c72cf3ea3e later
factored out into invalid_tparm_referent_p), but we need to also remove
the one in convert_nontype_argument_function for benefit of the first and
third testcase which we currently reject even in C++17/20 mode.

And in invalid_tparm_referent_p we're inadvertendly returning false for
the address of a lambda's static op() since it's DECL_ARTIFICIAL, which
currently causes us to reject the second (C++20) testcase.  But this
DECL_ARTIFICIAL check seems to be relevant only for VAR_DECL, and in fact
this code path was originally reachable only for VAR_DECL until recently
(r13-6970-gb5e38b1c166357).  So this patch restricts the check to VAR_DECL.

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

	PR c++/83258
	PR c++/80488
	PR c++/97700

gcc/cp/ChangeLog:

	* pt.cc (convert_nontype_argument_function): Remove linkage
	requirement for C++17 and later.
	(invalid_tparm_referent_p) <case ADDR_EXPR>: Restrict
	DECL_ARTIFICIAL rejection test to VAR_DECL.

gcc/testsuite/ChangeLog:

	* g++.dg/ext/visibility/anon8.C: Don't expect a "no linkage"
	error for the template argument &B2:fn in C++17 mode.
	* g++.dg/cpp0x/lambda/lambda-conv15.C: New test.
	* g++.dg/cpp2a/nontype-class56.C: New test.
	* g++.dg/template/function2.C: New test.

(cherry picked from commit c3afdb8b)

When late processing a noexcept-spec from a nested class after completion
of the outer class (since it's a complete-class context), we pass the wrong
class context to noexcept_override_late_checks -- the outer class type
instead of the nested class type -- which leads to bogus errors in the
below test.

This patch fixes this by making noexcept_override_late_checks obtain the
class context directly via DECL_CONTEXT instead of via an additional
parameter.

	PR c++/109761

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_class_specifier): Don't pass a class
	context to noexcept_override_late_checks.
	(noexcept_override_late_checks): Remove 'type' parameter
	and use DECL_CONTEXT of 'fndecl' instead.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/noexcept78.C: New test.

(cherry picked from commit c13906f2)

After r14-11-g2245459c85a3f4 we now coerce the template arguments of a
bound ttp again after level-lowering it.  Notably a level-lowered ttp
doesn't have DECL_CONTEXT set, so during this coercion we fall back to
using current_template_parms to obtain the relevant set of in-scope
parameters.

But it turns out current_template_parms isn't properly set when
substituting the function type of a generic lambda, and so if the type
contains bound ttps that need to be lowered we'll crash during their
attempted coercion.  Specifically in the first testcase below,
current_template_parms during the lambda type substitution (with T=int)
is "1 U" instead of the expected "2 TT, 1 U", and we crash when level
lowering TT<int>.

Ultimately the problem is that tsubst_lambda_expr does things in the
wrong order: we ought to substitute (and install) the in-scope template
parameters _before_ substituting anything that may use those template
parameters (such as the function type of a generic lambda).  This patch
corrects this substitution order.

	PR c++/109651

gcc/cp/ChangeLog:

	* pt.cc (coerce_template_args_for_ttp): Mention we can hit the
	current_template_parms fallback when level-lowering a bound ttp.
	(tsubst_template_decl): Add lambda_tparms parameter.  Prefer to
	use lambda_tparms instead of substituting DECL_TEMPLATE_PARMS.
	(tsubst_decl) <case TEMPLATE_DECL>: Pass NULL_TREE as lambda_tparms
	to tsubst_template_decl.
	(tsubst_lambda_expr): For a generic lambda, substitute
	DECL_TEMPLATE_PARMS and set current_template_parms to it
	before substituting the function type.  Pass the substituted
	DECL_TEMPLATE_PARMS as lambda_tparms to tsubst_template_decl.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/lambda-generic-ttp1.C: New test.
	* g++.dg/cpp2a/lambda-generic-ttp2.C: New test.

(cherry picked from commit 7bfb1550)

This is a backport of r14-739-gc62e945492afbb to keep the exported
symbol list consistent between trunk and gcc-13. The new assertions from
that commit are not part of this backport.

libstdc++-v3/ChangeLog:

	* config/abi/pre/gnu.ver: Export basic_string::_S_allocate.
	* include/bits/basic_string.h: (basic_string::_Alloc_traits_impl):
	Remove class template.
	(basic_string::_S_allocate): New static member function.
	(basic_string::assign): Use _S_allocate.
	* include/bits/basic_string.tcc (basic_string::_M_create)
	(basic_string::reserve, basic_string::_M_replace): Likewise.

(cherry picked from commit c62e9454)

As of https://go.dev/cl/476695 golang.org/x/sys/unix can call
syscall.prlimit, so we need such a function in libgo.

The trunk patch for this PR corrected the ABI for enums that have
a defined underlying type.  We shouldn't change the ABI on the branches
though, so this patch just removes the assertions that highlighed
the problem.

I think the same approach makes sense longer-term: keep the assertions
at maximum strength in trunk, and in any new branches that get cut.
Then, if the assertions trip an ABI problem, fix the problem in trunk
and remove the assertions from active branches.

The tests are the same as for the trunk version, but with all Wpsabi
message and expected output checks removed.

gcc/
	PR target/109661
	* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Remove
	assertion.
	(aarch64_layout_arg): Likewise.

gcc/testsuite/
	PR target/109661
	* g++.target/aarch64/pr109661-1.C: New test.
	* g++.target/aarch64/pr109661-2.C: Likewise.
	* g++.target/aarch64/pr109661-3.C: Likewise.
	* g++.target/aarch64/pr109661-4.C: Likewise.
	* gcc.target/aarch64/pr109661-1.c: Likewise.

The following forces the g++.dg/torture/pr106922.C testcase to use
the C++11 libstdc++ ABI and checks whether that worked.

gcc/testsuite/
	* g++.dg/torture/pr106922.C: Force _GLIBCXX_USE_CXX11_ABI to 1.

(cherry picked from commit a056a986)

	* ru.po: Update.

	* hr.po: Update.

http://eel.is/c++draft/dcl.attr#grammar-4 says
"In an attribute-list, an ellipsis may appear only if that attribute's
specification permits it."
and doesn't explicitly permit it on any standard attribute.
The https://wg21.link/p1774r8 paper which introduced assume attribute says
"We could therefore hypothetically permit the assume attribute to directly
support pack expansion:
template <int... args>
void f() {
[[assume(args >= 0)...]];
}
However, we do not propose this. It would require substantial additional work
for a very rare use case. Note that this can instead be expressed with a fold
expression, which is equivalent to the above and works out of the box without
any extra effort:
template <int... args>
void f() {
[[assume(((args >= 0) && ...))]];
}
", but as the testcase shows, GCC 13+ ICEs on assume attribute followed by
... if it contains packs.
The following patch rejects those instead of ICE and for C++17 or later
suggests using fold expressions instead (it doesn't make sense to suggest
it for C++14 and earlier when we'd error on the fold expressions).

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

	PR c++/109756
	* cp-gimplify.cc (process_stmt_assume_attribute): Diagnose pack
	expansion of assume attribute.

	* g++.dg/cpp23/attr-assume11.C: New test.

(cherry picked from commit 2499540e)

I came up with a testcase which reproduces all the way to r10-7469.
LTO to avoid early inlining it, so that ccp handles rotates and not
shifts before they are turned into rotates.

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

	PR tree-optimization/109778
	* gcc.dg/lto/pr109778_0.c: New test.
	* gcc.dg/lto/pr109778_1.c: New file.

(cherry picked from commit c2cf2dc9)

The following testcase is miscompiled, because bitwise ccp2 handles
a rotate with a signed type incorrectly.
Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3
arguments, all other callers just rotate in the right precision and
I think work correctly.  ccp works with widest_ints and so rotations
by the excessive precision certainly don't match what it wants
when it sees a rotate in some specific bitsize.  Still, if it is
unsigned rotate and the widest_int is zero extended from width,
the functions perform left shift and logical right shift on the value
and then at the end zero extend the result of left shift and uselessly
also the result of logical right shift and return | of that.
On the testcase we the signed char rrotate by 4 argument is
CONSTANT -75 i.e. 0xffffffff....fffffb5 with mask 2.
The mask is correctly rotated to 0x20, but because the 8-bit constant
is sign extended to 192-bit one, the logical right shift by 4 doesn't
yield expected 0xb, but gives 0xfffffffffff....ffffb, and then
return wi::zext (left, width) | wi::zext (right, width); where left is
0xfffffff....fb50, so we return 0xfb instead of the expected
0x5b.

The following patch fixes that by doing the zero extension in case of
the right variable before doing wi::lrshift rather than after it.

Also, wi::[lr]rotate widht width < precision always zero extends
the result.  I'm afraid it can't do better because it doesn't know
if it is done for an unsigned or signed type, but the caller in this
case knows that very well, so I've done the extension based on sgn
in the caller.  E.g. 0x5b rotated right (or left) by 4 with width 8
previously gave 0xb5, but sgn == SIGNED in widest_int it should be
0xffffffff....fffb5 instead.

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

	PR tree-optimization/109778
	* wide-int.h (wi::lrotate, wi::rrotate): Call wi::lrshift on
	wi::zext (x, width) rather than x if width != precision, rather
	than using wi::zext (right, width) after the shift.
	* tree-ssa-ccp.cc (bit_value_binop): Call wi::ext on the results
	of wi::lrotate or wi::rrotate.

	* gcc.c-torture/execute/pr109778.c: New test.

(cherry picked from commit a8302d2a)

__builtin_vsx_scalar_cmp_exp_qp_{eq,gt,lt,unordered} used
to be guarded with condition TARGET_P9_VECTOR before new
bif framework was introduced (r12-5752-gd08236359eb229),
since r12-5752 they are placed under stanza ieee128-hw,
that is to check condition TARGET_FLOAT128_HW, it caused
test case float128-cmp2-runnable.c to fail at -m32 as the
condition TARGET_FLOAT128_HW isn't satisified with -m32.

By checking the commit history, I didn't see any notes on
why this condition change on them was made, so this patch
is to move these bifs from stanza ieee128-hw to stanza
power9-vector as before.

	PR target/108758

gcc/ChangeLog:

	* config/rs6000/rs6000-builtins.def
	(__builtin_vsx_scalar_cmp_exp_qp_eq, __builtin_vsx_scalar_cmp_exp_qp_gt
	__builtin_vsx_scalar_cmp_exp_qp_lt,
	__builtin_vsx_scalar_cmp_exp_qp_unordered): Move from stanza ieee128-hw
	to power9-vector.

(cherry picked from commit 33a44e3a)

As PR109069 shows, commit r12-6537-g080a06fcb076b3 which
introduces define_insn_and_split sldoi_to_mov adopts
easy_vector_constant for const vector of interest, but it's
wrong since predicate easy_vector_constant doesn't guarantee
each byte in the const vector is the same.  One counter
example is the const vector in pr109069-1.c.  This patch is
to introduce new predicate const_vector_each_byte_same to
ensure all bytes in the given const vector are the same by
considering both int and float, meanwhile for the constants
which don't meet easy_vector_constant we need to gen a move
instead of just a set, and uses VECTOR_MEM_ALTIVEC_OR_VSX_P
rather than VECTOR_UNIT_ALTIVEC_OR_VSX_P for V2DImode support
under VSX since vector long long type of vec_sld is guarded
under stanza vsx.

	PR target/109069

gcc/ChangeLog:

	* config/rs6000/altivec.md (sldoi_to_mov<mode>): Replace predicate
	easy_vector_constant with const_vector_each_byte_same, add
	handlings in preparation for !easy_vector_constant, and update
	VECTOR_UNIT_ALTIVEC_OR_VSX_P with VECTOR_MEM_ALTIVEC_OR_VSX_P.
	* config/rs6000/predicates.md (const_vector_each_byte_same): New
	predicate.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/pr109069-1.c: New test.
	* gcc.target/powerpc/pr109069-2-run.c: New test.
	* gcc.target/powerpc/pr109069-2.c: New test.
	* gcc.target/powerpc/pr109069-2.h: New test.

(cherry picked from commit fd75f6ae)

Seemingly, the ptx JIT of CUDA <= 10.2 replaces function pointers in global
variables by NULL if a translation does not contain any executable code. It
works with CUDA 11.1.  The code of this commit is about reverse offload;
having NULL values disables the side of reverse offload during image load.

Solution is the same as found by Thomas for a related issue: Adding a dummy
procedure. Cf. the PR of this issue and Thomas' patch
"nvptx: Support global constructors/destructors via 'collect2'"
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607749.html



As that approach also works here:

Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>

gcc/
	PR libgomp/108098

	* config/nvptx/mkoffload.cc (process): Emit dummy procedure
	alongside reverse-offload function table to prevent NULL values
	of the function addresses.

(cherry picked from commit 4359724c)

aarch64_isa_flags (and aarch64_asm_isa_flags) are both aarch64_feature_flags (uint64_t)
but since r12-8000-g14814e20161d, they are saved/restored as unsigned long. This
does not make a difference for LP64 targets but on ILP32 and LLP64IL32 targets,
it means it does not get restored correctly.
This patch changes over to use aarch64_feature_flags instead of unsigned long.

Committed as obvious to gcc 13 branch after a bootstrap/test.

gcc/ChangeLog:

	PR target/109762
	* config/aarch64/aarch64-builtins.cc (aarch64_simd_switcher::aarch64_simd_switcher):
	Change argument type to aarch64_feature_flags.
	* config/aarch64/aarch64-protos.h (aarch64_simd_switcher): Change
	constructor argument type to aarch64_feature_flags.
	Change m_old_asm_isa_flags to be aarch64_feature_flags.

(cherry picked from commit a1a9ce24)

If there is a homogeneous struct with float128 members, they should be
copied to vector register save area. The current code incorrectly copies
only the value of the first member, not increasing the pointer with each
iteration. Fix this.

Merged from upstream libffi commit: 464b4b66e3cf3b5489e730c1466ee1bf825560e0

2023-05-03  Dan Horák <dan@danny.cz>

libffi/
	PR libffi/109447
	* src/powerpc/ffi_linux64.c (ffi_prep_args64): Update arg.f128 pointer.

(cherry picked from commit 043550bc)

The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR.

	PR c++/109506

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 9a9840ce)

This patch moves several tests introduced by the following patch:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html
  commit r14-325-gcacf65d74463600815773255e8b82b4043432bd7

into the proper location for OpenACC testing (thanks to Thomas for
spotting my mistake!), and also fixes a few additional problems --
missing diagnostics for non-pointer attaches, and a case where a pointer
was incorrectly dereferenced. Tests are also adjusted for vector-length
warnings on nvidia accelerators.

2023-04-29  Julian Brown  <julian@codesourcery.com>

	PR fortran/109622

gcc/fortran/
	* openmp.cc (resolve_omp_clauses): Add diagnostic for
	non-pointer/non-allocatable attach/detach.
	* trans-openmp.cc (gfc_trans_omp_clauses): Remove dereference for
	pointer-to-scalar derived type component attach/detach.  Fix
	attach/detach handling for descriptors.

gcc/testsuite/
	* gfortran.dg/goacc/pr109622-5.f90: New test.
	* gfortran.dg/goacc/pr109622-6.f90: New test.

libgomp/
	* testsuite/libgomp.fortran/pr109622.f90: Move test...
	* testsuite/libgomp.oacc-fortran/pr109622.f90: ...to here. Ignore
	vector length warning.
	* testsuite/libgomp.fortran/pr109622-2.f90: Move test...
	* testsuite/libgomp.oacc-fortran/pr109622-2.f90: ...to here.  Add
	missing copyin/copyout variable. Ignore vector length warnings.
	* testsuite/libgomp.fortran/pr109622-3.f90: Move test...
	* testsuite/libgomp.oacc-fortran/pr109622-3.f90: ...to here.  Ignore
	vector length warnings.
	* testsuite/libgomp.oacc-fortran/pr109622-4.f90: New test.

(cherry picked from commit 0a26a42b)