libgomp/
	* oacc-mem.c (acc_unmap_data): Don't open-code 'gomp_remove_var'.

Co-Authored-By: Julian Brown <julian@codesourcery.com>
(cherry picked from commit 2112d3242f413979931e371423dcead9d19440e7)

	libgomp/
	PR libgomp/92854
	* oacc-mem.c (acc_unmap_data): Remove 'tgt' reference counting.

(cherry picked from commit 4662f7fe7863b19fcc20ba58c22880f8d6661f3a)

	libgomp/
	PR libgomp/92854
	* testsuite/libgomp.oacc-c-c++-common/pr92854-1.c: Extend some
	more.

(cherry picked from commit af8fd1a99d9a21f8088ebb11250cd06a3f275052)

	libgomp/
	* oacc-mem.c (goacc_enter_datum): Use 'tgt' returned from
	'gomp_map_vars'.
	 (acc_map_data): Clean up accordingly.

Co-Authored-By: Julian Brown <julian@codesourcery.com>
(cherry picked from commit f233418ccf6a16eb3bf53018852c5f8926780143)

	libgomp/
	* testsuite/libgomp.oacc-fortran/deep-copy-6.f90: XFAIL behavior
	of over-eager 'finalize' clause.
	* testsuite/libgomp.oacc-fortran/deep-copy-6-no_finalize.F90: New
	file.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-1-1.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-1-2.F90: Likewise.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-2-1.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-2-2.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-3-1.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-3-2.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-4-1.f90: Likewise.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-4-2.f90: Likewise.

(cherry picked from commit 8d7794c0a2aa6696ab1a91ef209e8a9fe2df56ac)

	libgomp/
	* oacc-mem.c (goacc_exit_data_internal): Unlock on error path.

(cherry picked from commit 2e24d457d8c97e409549848715ff046cfa9efd3d)

	libgomp/
	* oacc-mem.c (acc_attach_async): Add missing gomp_mutex_unlock on
	error path.
	(goacc_detach_internal): Likewise.

Reviewed-by: Thomas Schwinge <thomas@codesourcery.com>
(cherry picked from commit dc9541545d9e5705a97c41713c557f55522b54dc)

If, for example, GCC is configured such that 'libgomp-plugin-nvptx.so.1'
dynamically links against 'libcuda.so.1', but testing is run on a system where
there is no 'libcuda.so.1', this produces output such as:

    PASS: libgomp.oacc-fortran/error_stop-1.f -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
    PASS: libgomp.oacc-fortran/error_stop-1.f -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O0  execution test
    FAIL: libgomp.oacc-fortran/error_stop-1.f -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O0  output pattern test, is  CheCKpOInT

    libgomp: while loading libgomp-plugin-nvptx.so.1: libcuda.so.1: cannot open shared object file: No such file or directory
    ERROR STOP

    Error termination. Backtrace: [...]
    , should match CheCKpOInT(
    |
    |^M)+ERROR STOP (
    |
    |^M)+Error termination.*

..., where after 'CheCKpOInT' we got 'libgomp: while loading [...]' injected
before the expected 'ERROR STOP'.

	libgomp/
	* testsuite/libgomp.oacc-fortran/error_stop-1.f: Initialize before
	the checkpoint.
	* testsuite/libgomp.oacc-fortran/error_stop-2.f: Likewise.
	* testsuite/libgomp.oacc-fortran/error_stop-3.f: Likewise.
	* testsuite/libgomp.oacc-fortran/stop-1.f: Likewise.
	* testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.
	* testsuite/libgomp.oacc-fortran/stop-3.f: Likewise.

(cherry picked from commit 1e378edd8f038c52914bc6cac8f6dd5a5c4f8a98)

When checking that a constrained partial specialization is more
constrained than the primary template, we pass only the innermost level
of generic template arguments to strictly_subsumes.  This leads to us
doing a nonsensical substitution from normalize_concept_check if the
full set of template arguments has multiple levels, and it ultimately
causes strictly_subsumes to sometimes erroneously return false as in the
testcase below.

gcc/cp/ChangeLog:

	* pt.c (process_partial_specialization): Pass the full set of
	generic template arguments to strictly_subsumes.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-partial-spec8.C: New test.

(cherry picked from commit c06280ac4c34b0aff8cfa2e74ae8c7afd759d52f)

When determining the most specialized partial specialization of a
primary template that is nested inside a class template, we first
tsubst the outer template arguments into the TEMPLATE_DECL of each
partial specialization, and then check for satisfaction of each of the
new TEMPLATE_DECL's constraints.

But tsubst_template_decl does not currently guarantee that constraints
from the original DECL_TEMPLATE_RESULT get reattached to the new
DECL_TEMPLATE_RESULT.  In the testcase below, this leads to the
constraints_satisfied_p check in most_specialized_partial_spec to
trivially return true for each of the partial specializations.

I'm not sure if such a guarantee would be desirable, but in this case we
can just check constraints_satisfied_p on the original TEMPLATE_DECL
instead of on the tsubsted TEMPLATE_DECL here, which is what this patch
does (alongside some reorganizing).

gcc/cp/ChangeLog:

	PR c++/92103
	* pt.c (most_specialized_partial_spec): Reorganize the loop over
	DECL_TEMPLATE_SPECIALIZATIONS.  Check constraints_satisfied_p on
	the original template declaration, not on the tsubsted one.

gcc/testsuite/ChangeLog:

	PR c++/92103
	* g++.dg/cpp2a/concepts-partial-spec7.C: New test.

(cherry picked from commit aee69073cdb8086d393f12474c6177e75467ceaa)

	* sv.po: Update.

This patch adds support for the Arm Zeus CPU.
Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/

2020-06-02  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

	* config/aarch64/aarch64-cores.def (zeus): Define.
	* config/aarch64/aarch64-tune.md: Regenerate.
	* doc/invoke.texi (AArch64 Options): Document zeus -mcpu option.

When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints.  Fix this by substituting through the constraints during
tsubst_lambda_expr.

gcc/cp/ChangeLog:

	PR c++/92633
	PR c++/92838
	* pt.c (tsubst_function_decl): Don't do set_constraints when
	regenerating a lambda.
	(tsubst_lambda_expr): Substitute into the lambda's constraints
	and do set_constraints here.

gcc/testsuite/ChangeLog:

	PR c++/92633
	PR c++/92838
	* g++.dg/cpp2a/concepts-lambda11.C: New test.
	* g++.dg/cpp2a/concepts-lambda12.C: New test.

(cherry picked from commit c2449995ca36ea955e3c6d4ee7f0d401b512c897)

In the testcase below we're prematurely folding away the
requires-expression to 'true' after substituting in the function's
template arguments, but before substituting in the lambda's deduced
template arguments.

This patch removes the uses_template_parms check when deciding in
tsubst_requires_expr whether to keep around a new requires-expression.
Regardless of whether the template arguments are dependent, there still
might be more template parameters to later substitute in (as in the
below testcase) and even if not, tsubst_expr doesn't perform full
semantic processing unless !processing_template_decl, so we should still
wait until then to fold away the requires-expression.

gcc/cp/ChangeLog:

	PR c++/95020
	* constraint.cc (tsubst_requires_expr): Produce a new
	requires-expression when processing_template_decl, even if
	template arguments are not dependent.

gcc/testsuite/ChangeLog:

	PR c++/95020
	* g++.dg/cpp2a/concepts-lambda7.C: New test.

(cherry picked from commit 7e52f8b1e03776575b92574252d9b6bbed9f1af4)

In the removal of arm-wrs-vxworks, the default cpu was updated from arm8
to armv7-a, but this is not recognized as a valid -mcpu target.  There
is however generic-armv7-a, which was likely the intended cpu that
should have been used instead.

gcc/ChangeLog:

	PR target/95420
	* config.gcc (arm-wrs-vxworks7*): Set default cpu to generic-armv7-a.

(cherry picked from commit 86b14bb1a93d8ef01678d132013a2006a4f00deb)

The va_list type for Alpha includes a nameless dummy field for alignment
purposes.  To transpose this into D, a field named "__pad%d" is inserted
into the struct definition.

It was also noticed that in the D front-end AST copy of the backend
type, all offsets for fields generated by build_frontend_type were set
to zero due to a wrong assumption that DECL_FIELD_OFFSET would have a
non-zero value.  This has been fixed to use byte_position instead.

gcc/d/ChangeLog:

	* d-builtins.cc (build_frontend_type): Handle struct fields with NULL
	DECL_NAME.  Use byte_position to get the real field offset.

(cherry picked from commit 70f6320462d91e5add99ae5b50226356302a8c0b)

This patch fixes a 8/9/10/11 regression, where finalized types
were not finalized (and deallocated), which led to memory
leaks.

gcc/fortran/ChangeLog:

2020-05-24  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/94361
	* class.c (finalize_component): Use expr->finalized instead of
	comp->finalized.
	* gfortran.h (gfc_component): Remove finalized member.
	(gfc_expr): Add it here instead.

gcc/testsuite/ChangeLog:

2020-05-24  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/94361
	* gfortran.dg/finalize_28.f90: Adjusted free counts.
	* gfortran.dg/finalize_33.f90: Likewise.
	* gfortran.dg/finalize_34.f90: Likewise.
	* gfortran.dg/finalize_35.f90: New test.

(cherry picked from commit 811f902b764c5a13178cbd7588e96c16b3fab504)

In the testcase below, the satisfaction value of fn1<int>'s constraint
is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
to the standard boolean_type_node.  But satisfaction_value expects to
see exactly boolean_true_node or integer_one_node, which this value is
neither, causing us to trip over the assert therein.

This patch relaxes satisfaction_value to accept any INTEGER_CST which
satisfies integer_zerop or integer_onep.

gcc/cp/ChangeLog:

	PR c++/95386
	* constraint.cc (satisfaction_value): Relax to accept any
	INTEGER_CST that satisfies integer_zerop or integer_onep.

gcc/testsuite/ChangeLog:

	PR c++/95386
	* g++.dg/concepts/pr95386.C: New test.

When parsing a constraint-expression, a requires-clause or a
requires-expression, we temporarily increment processing_template_decl
so that we always obtain template trees which we could later reduce via
substitution even when not inside a template.

But incrementing processing_template_decl when we're already inside a
template has the unintended side effect of shifting up the template
parameter levels of a lambda defined inside one of these constructs,
which leads to confusion later during substitution into the lambda.

This patch fixes this issue by incrementing processing_template_decl
during parsing of these constructs only if it is 0.

gcc/cp/ChangeLog:

	PR c++/92652
	PR c++/93698
	PR c++/94128
	* parser.c (cp_parser_requires_clause_expression): Temporarily
	increment processing_template_decl only if it is 0.
	(cp_parser_constraint_expression): Likewise.
	(cp_parser_requires_expression): Likewise.

gcc/testsuite/ChangeLog:

	PR c++/92652
	PR c++/93698
	PR c++/94128
	* g++.dg/cpp2a/concepts-lambda8.C: New test.
	* g++.dg/cpp2a/concepts-lambda9.C: New test.
	* g++.dg/cpp2a/concepts-lambda10.C: New test.

(cherry picked from commit 020d86db8896f088435830595640e6fc21bc64ad)

In the testcase below, the CONSTRUCTOR for 'field' contains a RANGE_EXPR
index:

  {{aggr_init_expr<...>, [1...2]={.off=1}}}

but get_or_insert_ctor_field isn't prepared to handle looking up a
RANGE_EXPR index.

This patch adds limited support to get_or_insert_ctor_field for looking
up a RANGE_EXPR index.  The limited scope of this patch should make it
more suitable for backporting, and more extensive support would be
needed only to handle self-modifying CONSTRUCTORs that contain a
RANGE_EXPR index, but I haven't yet been able to come up with a testcase
that actually creates such a CONSTRUCTOR.

gcc/cp/ChangeLog:

	PR c++/95241
	* constexpr.c (get_or_insert_ctor_field): Add limited support
	for RANGE_EXPR index lookups.

gcc/testsuite/ChangeLog:

	PR c++/95241
	* g++.dg/cpp0x/constexpr-array25.C: New test.

(cherry picked from commit e069285cdf457cc85070e522380c4e25b0d2ed25)

When comparing two special member function templates to see if one hides
the other (as per P0848R3), we need to check satisfaction which we can't
do on templates.  So this patch makes add_method skip the eligibility
test on member function templates and just lets them coexist.

gcc/cp/ChangeLog:

	PR c++/95181
	* class.c (add_method): Let special member function templates
	coexist if they are not equivalently constrained, or in a class
	template.

gcc/testsuite/ChangeLog:

	PR c++/95181
	* g++.dg/concepts/pr95181.C: New test.
	* g++.dg/concepts/pr95181-2.C: New test.

Co-authored-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 6b449b74c590f5a6f66c73aed894e5b5b36aa59d)

gcc/cp/ChangeLog:

	PR c++/95371
	* pt.c (process_template_parm): Set DECL_TEMPLATE_INFO
	on the DECL_TEMPLATE_RESULT.

gcc/testsuite/ChangeLog:

	PR c++/95371
	* g++.dg/cpp2a/concepts-ttp1.C: New test.

(cherry picked from commit d91b3aea7a5bdfbdaec746af2d62894812e6fd86)

I have noticed we don't export these 6 symbols and thus the testcase
below fails to link.

2020-05-29  Jakub Jelinek  <jakub@redhat.com>

	PR libfortran/95390
	* gfortran.dg/findloc_8.f90: New test.

	* Makefile.am (i_findloc0_c): Add findloc0_i10.c.
	(i_findloc1_c): Add findloc1_i10.c.
	* gfortran.map (GFORTRAN_10.2): New symbol version, export
	_gfortran_{,m,s}findloc{0,1}_c10 symbols.
	* Makefile.in: Regenerated.
	* generated/findloc0_c10.c: Generated.
	* generated/findloc1_c10.c: Generated.

(cherry picked from commit 316fe6b40165c26b30375f8ad85384379133f89b)

This test uses C++11 features so should only run in c++11.

	* g++.dg/ext/tmplattr10.C: Only run in c++11.

This fixes PR94591. The problem was the function aarch64_evpc_rev_local()
matching vector permutations that were not reversals. In particular, prior to
this patch, this function matched the identity permutation which led to
generating bogus REV64 insns which were rejected by the assembler.

gcc/
	PR target/94591
	* config/aarch64/aarch64.c (aarch64_evpc_rev_local): Don't match
	identity permutation.

gcc/testsuite/
	PR target/94591
	* gcc.c-torture/execute/pr94591.c: New test.

(cherry picked from commit 98452668d362bb9e6358f7eb5cff69f4f5ab1d45)

This switches the code that expands scalar addresses to vectors of addresses
from using VCC to using CC_SAVE_REG, for the lo-part to hi-part carry values.
These were fine in code expanded in earlier passes, but addresses expanded
late, such as for stack spills or reloads, could clobber live VCC values,
causing execution failures.

This is the first target-specific testcase for GCN, so the new .exp file is
included.

Backport from master:

	gcc/
	* config/gcn/gcn-valu.md (add<mode>3_zext_dup): Change to a
	define_expand, and rename the original to ...
	(add<mode>3_vcc_zext_dup): ... this, and add a custom VCC operand.
	(add<mode>3_zext_dup_exec): Likewise, with ...
	(add<mode>3_vcc_zext_dup_exec): ... this.
	(add<mode>3_zext_dup2): Likewise, with ...
	(add<mode>3_zext_dup_exec): ... this.
	(add<mode>3_zext_dup2_exec): Likewise, with ...
	(add<mode>3_zext_dup2): ... this.
	* config/gcn/gcn.c (gcn_expand_scalar_to_vector_address): Switch
	addv64di3_zext* calls to use addv64di3_vcc_zext*.

	gcc/testsuite/
	* gcc.target/gcn/gcn.exp: New file.
	* gcc.target/gcn/vcc-clobber.c: New file.

gcc/ChangeLog:
2020-05-27  Dong JianQiang  <dongjianqiang2@huawei.com>

	PR gcov-profile/95332
	* gcov-io.c (gcov_var::endian): Move field.
	(from_file): Add IN_GCOV_TOOL check.
	* gcov-io.h (gcov_magic): Ditto.

libgcc/ChangeLog:
2020-05-27  Dong JianQiang  <dongjianqiang2@huawei.com>

	PR gcov-profile/95332
	* libgcov-util.c (read_gcda_file): Call gcov_magic.
	* libgcov.h (gcov_magic): Disable GCC poison.

(cherry picked from commit 17d1594bfe08f3c768e024b180816cbe37ac08ac)

I've just tested the script and I'm going to install the patch
to all active branches.

contrib/ChangeLog:

	* git-backport.py: The script did 'git co HEAD~' when
	there was no modified ChangeLog file in a successful
	git cherry pick.
	Run cherry-pick --continue without editor.

(cherry picked from commit 24663f1f6d709daf8913484914ed01af9f7a480a)

The initial commit for this PR uncovered a latent issue with unit locking
in the Fortran run-time library.  Add check for valid unit.

2020-05-28  Harald Anlauf  <anlauf@gmx.de>

libgfortran/
	PR libfortran/95104
	* io/unit.c (unlock_unit): Guard by check for NULL pointer.

(cherry picked from commit 6ce3d791dfcba469e709935aba5743640f7d4959)

The stack frame for the function in the testcase consisted of two
SVE save slots.  Both saves had been shrink-wrapped, but for different
blocks, meaning that the stack allocation and deallocation were
separate from the saves themselves.  Before emitting the deallocation,
we tried to attach a REG_CFA_DEF_CFA note to the preceding instruction,
to redefine the CFA in terms of the stack pointer.  But in this case
there was no preceding instruction.

This in practice only happens for SVE because:

(a) We don't try to shrink-wrap wb_candidate* registers even when
    we've decided to treat them as normal saves and restores.
    I have a fix for that.

(b) Even with (a) fixed, we're (almost?) guaranteed to emit
    a stack tie for frames that are 64k or larger, so we end
    up hanging the REG_CFA_DEF_CFA note on that instead.

We should only need to redefine the CFA if it was previously
defined in terms of the frame pointer.  In other cases the CFA
should already be defined in terms of the stack pointer,
so redefining it is unnecessary but usually harmless.

2020-05-28  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
	PR testsuite/95361
	* config/aarch64/aarch64.c (aarch64_expand_epilogue): Only
	redefine the CFA if we have CFI operations.

gcc/testsuite/
	PR testsuite/95361
	* gcc.target/aarch64/sve/pr95361.c: New test.

Based on a patch in the comments of the PR. That patch fixed this
problem but caused the test cases for PR93484 to fail. It has been
changed to reduce initialisation expressions if the expression is
not EXPR_VARIABLE and not EXPR_CONSTANT.

2020-05-28  Steven G. Kargl  <kargl@gcc.gnu.org>
	    Mark Eggleston  <markeggleston@gcc.gnu.org>

gcc/fortran/

	PR fortran/94397
	* match.c (gfc_match_type_spec): New variable ok initialised
	to true. Set ok with the return value of gfc_reduce_init_expr
	called only if the expression is not EXPR_CONSTANT and is not
	EXPR_VARIABLE. Add !ok to the check for type not being integer
	or the rank being greater than zero.

2020-05-28  Mark Eggleston  <markeggleston@gcc.gnu.org>

gcc/testsuite/

	PR fortran/94397
	* gfortran.dg/pr94397.F90: New test.

(cherry picked from commit 3ea6977d0f1813d982743a09660eec1760e981ec)

PFPNACC insn is incorrectly modelled to perform addition and subtraction
of two operands, but in reality it performs horizontal addition and
subtraction:

Instruction: PFPNACC dest,src

Description:
dest[31:0] <- dest[31:0] - dest[63:32];
dest[63:32] <- src[31:0] + src[63:32];

2020-05-28  Uroš Bizjak  <ubizjak@gmail.com>

gcc/ChangeLog:
	* config/i386/mmx.md (mmx_haddsubv2sf3): Correct
	RTL template to model horizontal subtraction and addition.

2020-05-28  Uroš Bizjak  <ubizjak@gmail.com>

gcc/ChangeLog:
	PR target/95355
	* config/i386/sse.md
	(<mask_codefor>avx512f_<code>v16qiv16si2<mask_name>):
	Remove %q operand modifier from insn template.
	(avx512f_<code>v8hiv8di2<mask_name>): Ditto.

gcc/testsuite/ChangeLog:
	PR target/95355
	* gcc.target/i386/pr95355.c: New test.