This is a release branch version of
r11-1741-g:31427b974ed7b7dd54e28fec595e731bf6eea8ba and
r11-2022-g:efe99cca78215e339ba79f0a900a896b4c0a3d36.

The trunk versions of the patch made GNU and Advanced SIMD vectors
distinct (but inter-convertible) in all cases.  However, the
traditional behaviour is that the types are distinct in template
arguments but not otherwise.

Following a suggestion from Jason, this patch puts the check
for different vector types under comparing_specializations.
In order to keep the backport as simple as possible, the patch
hard-codes the name of the attribute in the frontend rather than
adding a new branch-only target hook.

I didn't find a test that tripped the assert on the branch,
even with the --param in the PR, so instead I tested this by
forcing the hash function to only hash the tree code.  That made
the static assertion in the test fail without the patch but pass
with it.

This means that the tests pass for unmodified sources even
without the patch (unless you're very unlucky).

gcc/
	PR target/95726
	* config/aarch64/aarch64.c (aarch64_attribute_table): Add
	"Advanced SIMD type".
	* config/aarch64/aarch64-builtins.c: Include stringpool.h and
	attribs.h.
	(aarch64_init_simd_builtin_types): Add an "Advanced SIMD type"
	attribute to each Advanced SIMD type.
	* config/arm/arm.c (arm_attribute_table): Add "Advanced SIMD type".
	* config/arm/arm-builtins.c: Include stringpool.h and attribs.h.
	(arm_init_simd_builtin_types): Add an "Advanced SIMD type"
	attribute to each Advanced SIMD type.

gcc/cp/
	PR target/95726
	* typeck.c (structural_comptypes): When comparing template
	specializations, differentiate between vectors that have and
	do not have an "Advanced SIMD type" attribute.

gcc/testsuite/
	PR target/95726
	* g++.target/aarch64/pr95726.C: New test.
	* g++.target/arm/pr95726.C: Likewise.

The _mm512_{,mask_}cmp_p[ds]_mask and also _mm_{,mask_}cmp_s[ds]_mask
intrinsics have an argument which must have a constant passed to it
and so use an inline version only for ifdef __OPTIMIZE__ and have
a #define for -O0.  But the _mm512_{,mask_}cmp*_p[ds]_mask intrinsics
don't need a constant argument, they are essentially the first
set with the constant added to them implicitly based on the comparison
name, and so there is no #define version for them (correctly).
But their inline versions are defined in between the first and s[ds]
set and so inside of ifdef __OPTIMIZE__, which means that with -O0
they aren't defined at all.

This patch fixes that by moving those after the #ifdef __OPTIMIZE #else
use #define #endif block.

2020-07-15  Jakub Jelinek  <jakub@redhat.com>

	PR target/96174
	* config/i386/avx512fintrin.h (_mm512_cmpeq_pd_mask,
	_mm512_mask_cmpeq_pd_mask, _mm512_cmplt_pd_mask,
	_mm512_mask_cmplt_pd_mask, _mm512_cmple_pd_mask,
	_mm512_mask_cmple_pd_mask, _mm512_cmpunord_pd_mask,
	_mm512_mask_cmpunord_pd_mask, _mm512_cmpneq_pd_mask,
	_mm512_mask_cmpneq_pd_mask, _mm512_cmpnlt_pd_mask,
	_mm512_mask_cmpnlt_pd_mask, _mm512_cmpnle_pd_mask,
	_mm512_mask_cmpnle_pd_mask, _mm512_cmpord_pd_mask,
	_mm512_mask_cmpord_pd_mask, _mm512_cmpeq_ps_mask,
	_mm512_mask_cmpeq_ps_mask, _mm512_cmplt_ps_mask,
	_mm512_mask_cmplt_ps_mask, _mm512_cmple_ps_mask,
	_mm512_mask_cmple_ps_mask, _mm512_cmpunord_ps_mask,
	_mm512_mask_cmpunord_ps_mask, _mm512_cmpneq_ps_mask,
	_mm512_mask_cmpneq_ps_mask, _mm512_cmpnlt_ps_mask,
	_mm512_mask_cmpnlt_ps_mask, _mm512_cmpnle_ps_mask,
	_mm512_mask_cmpnle_ps_mask, _mm512_cmpord_ps_mask,
	_mm512_mask_cmpord_ps_mask): Move outside of __OPTIMIZE__ guarded
	section.

	* gcc.target/i386/avx512f-vcmppd-3.c: New test.
	* gcc.target/i386/avx512f-vcmpps-3.c: New test.

(cherry picked from commit 12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c)

This reverts commit 8147c741.

2020-07-15  Richard Biener  <rguenther@suse.de>

	PR bootstrap/96203
	* lto-opts.c: Revert changes.
	* lto-wrapper.c: Likewise.

convert_like issues errors about bad_p conversions at the beginning
of the function, but in the ck_ref_bind case, it only issues them
after we've called convert_like on the next conversion.

This doesn't work as expected since r10-7096 because when we see
a conversion from/to class type in a template, we return early, thereby
missing the error, and a bad_p conversion goes by undetected.  That
made the attached test to compile even though it should not.

I had thought that I could just move the ck_ref_bind/bad_p errors
above to the rest of them, but that regressed diagnostics because
expr then wasn't converted yet by the nested convert_like_real call.

So, for bad_p conversions, do the normal processing, but still return
the IMPLICIT_CONV_EXPR to avoid introducing trees that the template
processing can't handle well.  This I achieved by adding a wrapper
function.

gcc/cp/ChangeLog:

	PR c++/95789
	PR c++/96104
	PR c++/96179
	* call.c (convert_like_real_1): Renamed from convert_like_real.
	(convert_like_real): New wrapper for convert_like_real_1.

gcc/testsuite/ChangeLog:

	PR c++/95789
	PR c++/96104
	PR c++/96179
	* g++.dg/conversion/ref4.C: New test.
	* g++.dg/conversion/ref5.C: New test.
	* g++.dg/conversion/ref6.C: New test.

(cherry picked from commit 8e64d182850560dbedfabb88aac90d4fc6155067)

The version of nvprof in CUDA 9.0 causes a hang when used to profile an
OpenACC program.  This is because it calls acc_get_device_type from
a callback called during device initialization, which then attempts
to acquire acc_device_lock while it is already taken, resulting in
deadlock.  This works around the issue by returning acc_device_none
from acc_get_device_type without attempting to acquire the lock when
initialization has not completed yet.

2020-07-14  Tom de Vries  <tom@codesourcery.com>
	    Cesar Philippidis  <cesar@codesourcery.com>
	    Thomas Schwinge  <thomas@codesourcery.com>
	    Kwok Cheung Yeung  <kcy@codesourcery.com>

	libgomp/
	* oacc-init.c (acc_init_state_lock, acc_init_state, acc_init_thread):
	New variable.
	(acc_init_1): Set acc_init_thread to pthread_self ().  Set
	acc_init_state to initializing at the start, and to initialized at the
	end.
	(self_initializing_p): New function.
	(acc_get_device_type): Return acc_device_none if called by thread that
	is currently executing acc_init_1.
	* libgomp.texi (acc_get_device_type): Update documentation.
	(Implementation Status and Implementation-Defined Behavior): Likewise.
	* testsuite/libgomp.oacc-c-c++-common/acc_prof-init-2.c: New.

(cherry picked from commit b52643ab9004ba8ecea06a399885fe1e04183eda)

The testcase has failed since r9-5035, because obj_type_ref_class
tries to look up an ODR type when no ODR type information is
available.  (The information was available earlier in the
compilation, but was freed during pass_ipa_free_lang_data.)
We then crash dereferencing the null get_odr_type result.

The test passes with -O2.  However, it fails again if -fdump-tree-all
is used, since obj_type_ref_class is called indirectly from the
dump routines.

Other code creates ODR type entries on the fly by passing “true”
as the insert parameter.  But obj_type_ref_class can't do that
unconditionally, since it should have no side-effects when used
from the dumping code.

Following a suggestion from Honza, this patch adds parameters
to say whether the routines are being called from dump routines
and uses those to derive the insert parameter.

gcc/
	PR middle-end/95114
	* tree.h (virtual_method_call_p): Add a default-false parameter
	that indicates whether the function is being called from dump
	routines.
	(obj_type_ref_class): Likewise.
	* tree.c (virtual_method_call_p): Likewise.
	* ipa-devirt.c (obj_type_ref_class): Likewise.  Lazily add ODR
	type information for the type when the parameter is false.
	* tree-pretty-print.c (dump_generic_node): Update calls to
	virtual_method_call_p and obj_type_ref_class accordingly.

gcc/testsuite/
	PR middle-end/95114
	* g++.target/aarch64/pr95114.C: New test.

The range infrastructure has code to decompose POLY_INT_CST ranges
to worst-case integer bounds.  However, it had the fundamental flaw
(obvious in hindsight) that it applied to anti-ranges too, meaning
that a range 2+2X would end up with a range of ~[2, +INF], i.e.
[-INF, 1].  This patch decays to varying in that case instead.

I'm still a bit uneasy about this.  ISTM that in terms of
generality:

  SSA_NAME => POLY_INT_CST => INTEGER_CST
           => ADDR_EXPR

I.e. an SSA_NAME could store a POLY_INT_CST and a POLY_INT_CST
could store an INTEGER_CST (before canonicalisation).  POLY_INT_CST
is also “as constant as” ADDR_EXPR (well, OK, only some ADDR_EXPRs
are run-time rather than link-time constants, whereas all POLY_INT_CSTs
are, but still).  So it seems like we should at least be able to treat
POLY_INT_CST as symbolic.  On the other hand, I don't have any examples
in which that would be useful.

gcc/
	PR tree-optimization/96146
	* value-range.cc (value_range::set): Only decompose POLY_INT_CST
	bounds to integers for VR_RANGE.  Decay to VR_VARYING for anti-ranges
	involving POLY_INT_CSTs.

gcc/testsuite/
	PR tree-optimization/96146
	* gcc.target/aarch64/sve/acle/general/pr96146.c: New test.

> > The store to the whole of each volatile object was picked apart
> > like there had been an individual assignment to each of the
> > fields.  Reads were added as part of that; see PR for details.
> > The reads from volatile memory were a clear bug; individual
> > stores questionable.  A separate patch clarifies the docs.

This breaks building of mesa on both the trunk and 10 branch.

The problem is that the middle-end may never create temporaries of non-POD
(TREE_ADDRESSABLE) types, those can be only created when the language says
so and thus only the FE is allowed to create those.

This patch just reverts the behavior to what we used to do before for the
stores to volatile non-PODs.  Perhaps we want to do something else, but
definitely we can't create temporaries of the non-POD type.  It is up to
discussions on what should happen in those cases.

2020-07-14  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/96194
	* expr.c (expand_constructor): Don't create temporary for store to
	volatile MEM if exp has an addressable type.

	* g++.dg/opt/pr96194.C: New test.

(cherry picked from commit b1d389d60d1929c7528ef984925ea010e3bf2c1a)

2020-07-14  Matthias Klose  <doko@ubuntu.com>

	PR lto/95604
	* lto-wrapper.c (merge_and_complain): Add decoded options as parameter,
	error on different values for -fcf-protection.
	(append_compiler_options): Pass -fcf-protection option.
	(find_and_merge_options): Add decoded options as parameter,
	pass decoded_options to merge_and_complain.
	(run_gcc): Pass decoded options to find_and_merge_options.
	* lto-opts.c (lto_write_options): Pass -fcf-protection option.

(cherry picked from commit 6a48d12475cdb7375b98277f8bc089715feeeafe)

Because the check for power10_hw is not called
check_effective_target_power10_hw, it needs to be looked
for by is-effective-target-keyword. Also reorder things
in is-effective-target to put power10_hw with the other
ppc stuff.

2020-07-13  Aaron Sawdey  <acsawdey@linux.ibm.com>

gcc/testsuite/

	* lib/target-supports.exp (is-effective-target):
	Reorder to put powerpc stuff together.
	(is-effective-target-keyword): Add power10_hw.

(cherry picked from commit 94c7c67b82dd7255fde0d7ae42d483336ea1b60b)

Add a test for dejagnu to determine if execution of MMA instructions is
supported in the test environment. Add an execution test to make sure
that __builtin_cpu_supports("mma") is true if we can execute MMA
instructions.

2020-07-13  Aaron Sawdey  <acsawdey@linux.ibm.com>

gcc/testsuite/

	* lib/target-supports.exp (check_ppc_mma_hw_available):
	New function.
	(is-effective-target): Add ppc_mma_hw.
	(is-effective-target-keyword): Add ppc_mma_hw.
	* gcc.target/powerpc/mma-supported.c: New file.
	* gcc.target/powerpc/mma-single-test.c: Require ppc_mma_hw.
	* gcc.target/powerpc/mma-double-test.c: Require ppc_mma_hw.

(cherry picked from commit 305ab735bd40b52a451851fa6e2177f184eb05d4)

Define the __ARM_FEATURE_PAC_DEFAULT feature test
macro when PAC-RET branch protection is enabled.

2020-07-13  Szabolcs Nagy  <szabolcs.nagy@arm.com>

gcc/ChangeLog:

	* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add
	__ARM_FEATURE_PAC_DEFAULT support.

(cherry picked from commit a1faa8e2470b33e92f6274804bf7941fbb6e2d38)

The expected semantics and valid usage of __builtin_return_address is
not clear since it exposes implementation internals that are normally
not meaningful to portable c code.

This documentation change tries to clarify the semantics in case the
return address is stored in a mangled form. This affects AArch64 when
pointer authentication is used for the return address signing (i.e.
-mbranch-protection=pac-ret).

2020-07-13  Szabolcs Nagy  <szabolcs.nagy@arm.com>

gcc/ChangeLog:

	PR target/94891
	* doc/extend.texi: Update the text for  __builtin_return_address.

(cherry picked from commit 6a391e06f953c3390b14020d8cacb6d55f81b2b9)

Mangling, currently only used on AArch64 for return address signing,
is an internal representation that should not be exposed via

  __builtin_return_address return value,
  __builtin_eh_return handler argument,
  _Unwind_DebugHook handler argument.

Note that a mangled address might not even fit into a void *, e.g.
with AArch64 ilp32 ABI the return address is stored as 64bit, so
the mangled return address cannot be accessed via _Unwind_GetPtr.

This patch changes the unwinder hooks as follows:

MD_POST_EXTRACT_ROOT_ADDR is removed: root address comes from
__builtin_return_address which is not mangled.

MD_POST_EXTRACT_FRAME_ADDR is renamed to MD_DEMANGLE_RETURN_ADDR,
it now operates on _Unwind_Word instead of void *, so the hook
should work when return address signing is enabled on AArch64 ilp32.
(But for that __builtin_aarch64_autia1716 should be fixed to operate
on 64bit input instead of a void *.)

MD_POST_FROB_EH_HANDLER_ADDR is removed: it is the responsibility of
__builtin_eh_return to do the mangling if necessary.

2020-07-13  Szabolcs Nagy  <szabolcs.nagy@arm.com>

libgcc/ChangeLog:

	PR target/94891
	* config/aarch64/aarch64-unwind.h (MD_POST_EXTRACT_ROOT_ADDR): Remove.
	(MD_POST_FROB_EH_HANDLER_ADDR): Remove.
	(MD_POST_EXTRACT_FRAME_ADDR): Rename to ...
	(MD_DEMANGLE_RETURN_ADDR): This.
	(aarch64_post_extract_frame_addr): Rename to ...
	(aarch64_demangle_return_addr): This.
	(aarch64_post_frob_eh_handler_addr): Remove.
	* unwind-dw2.c (uw_update_context): Demangle return address.
	(uw_frob_return_addr): Remove.

(cherry picked from commit b097c7a27fb0796b2653a1d003cbf6b7a69d8961)

Currently __builtin_eh_return takes a signed return address, which can
cause ABI and API issues: 1) pointer representation problems if the
address is passed around before eh return, 2) the source code needs
pac-ret specific changes and needs to know if pac-ret is used in the
current frame, 3) signed address may not be representible as void *
(with ilp32 abi).

Using address signing to protect eh return is ineffective because the
instruction sequence in the unwinder that starts from the address
signing and ends with a ret can be used as a return to anywhere gadget.
Using indirect branch istead of ret with bti j landing pads at the
target can reduce the potential of such gadget, which also implies
that __builtin_eh_return should not take a signed address.

This is a big hammer fix to the ABI and API issues: it turns pac-ret
off for the caller completely (not just on the eh return path).  To
harden the caller against ROP attacks, it should use indirect branch
instead of ret, this is not attempted so the patch remains small and
backportable.

2020-07-13  Szabolcs Nagy  <szabolcs.nagy@arm.com>

gcc/ChangeLog:

	PR target/94891
	* config/aarch64/aarch64.c (aarch64_return_address_signing_enabled):
	Disable return address signing if __builtin_eh_return is used.

gcc/testsuite/ChangeLog:

	PR target/94891
	* gcc.target/aarch64/return_address_sign_1.c: Update test.
	* gcc.target/aarch64/return_address_sign_b_1.c: Likewise.

(cherry picked from commit 2bc95be3bb8c8138e2e87c1c11c84bfede989d61)

This is a big hammer fix for __builtin_return_address (PR target/94891)
returning signed addresses (sometimes, depending on wether lr happens
to be signed or not at the time of call which depends on optimizations),
and similarly -pg may pass signed return address to _mcount
(PR target/94791).

At the time of return address expansion we don't know if it's signed or
not so it is done unconditionally.

2020-07-13  Szabolcs Nagy  <szabolcs.nagy@arm.com>

gcc/ChangeLog:

	PR target/94891
	PR target/94791
	* config/aarch64/aarch64-protos.h (aarch64_return_addr_rtx): Declare.
	* config/aarch64/aarch64.c (aarch64_return_addr_rtx): New.
	(aarch64_return_addr): Use aarch64_return_addr_rtx.
	* config/aarch64/aarch64.h (PROFILE_HOOK): Likewise.

(cherry picked from commit 463a54e5d4956143f81c1f23b91cbd2d93855741)

sjlj.S did not have the GNU property note markup and the BTI c
instructions that are necessary when it is built with branch
protection.

The notes are only added when libitm is built with branch
protection, because old linkers mishandle the note (merge
them incorrectly or emit warnings), the BTI instructions
are added unconditionally.

2020-07-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

libitm/ChangeLog:

	* config/aarch64/sjlj.S: Add BTI marking and related definitions,
	and add BTI c to function entries.

(cherry picked from commit 319078dad62eba942d33c8975bdcbb09d1c68ba6)

lse.S did not have the GNU property note markup and the BTI c
instructions that are necessary when it is built with branch
protection.

The notes are only added when libgcc is built with branch
protection, because old linkers mishandle the note (merge
them incorrectly or emit warnings), the BTI instructions
are added unconditionally.

Note: BTI c is only necessary at function entry if the function
may be called indirectly, currently lse functions are not called
indirectly, but BTI is added for ABI reasons e.g. to allow
linkers later to emit stub code with indirect jump.

2020-07-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

libgcc/ChangeLog:

	PR target/96001
	* config/aarch64/lse.S: Add BTI marking and related definitions,
	and add BTI c to function entries.

(cherry picked from commit f0f62fa0320762119446893c67cb52934bc5a05e)

lse.S did not have GNU stack note, this may cause missing
PT_GNU_STACK in binaries on Linux and FreeBSD.

2020-07-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

libgcc/ChangeLog:

	* config/aarch64/lse.S: Add stack note.

(cherry picked from commit e73ec755489afc9fcc75dfac6f06ac73e243e72a)

sjlj.S only had the note on Linux, but it is supposed
to have it on FreeBSD too.

2020-07-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

libitm/ChangeLog:

	* config/aarch64/sjlj.S: Add stack note if __FreeBSD__ is defined.

(cherry picked from commit 463ba375f7b857995068403a4c63690d03162c00)

Define the __ARM_FEATURE_BTI_DEFAULT feature test
macro when BTI branch protection is enabled.

2020-07-09  Szabolcs Nagy  <szabolcs.nagy@arm.com>

gcc/ChangeLog:

	* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add
	__ARM_FEATURE_BTI_DEFAULT support.

(cherry picked from commit 63b6808e69699ba576492efa29d92b626cc26eba)

OpenACC 2.6 specifies that the array descriptor (when present) must be
copied to the target before attaching pointers in Fortran. This patch
reverses the stripping of GOMP_MAP_TO_PSET and GOMP_MAP_POINTER that
was introduced by the "OpenACC reference count overhaul" patch.

2020-07-10  Julian Brown  <julian@codesourcery.com>
	    Thomas Schwinge  <thomas@codesourcery.com>

gcc/
	* gimplify.c (gimplify_scan_omp_clauses): Do not strip
	GOMP_MAP_TO_PSET/GOMP_MAP_POINTER for OpenACC enter/exit data
	directives (see also PR92929).

gcc/testsuite/
	* gfortran.dg/goacc/finalize-1.f: Update expected dump output.

libgomp/
	* testsuite/libgomp.oacc-fortran/dynamic-pointer-1.f90: New test.

Co-Authored-By: Thomas Schwinge <thomas@codesourcery.com>
(cherry picked from commit b20097c65d2e74b1901fba1c55c77f0407e542d2)

This patch adjusts how dynamic reference counts work so that they match
the semantics of the source program more closely, instead of representing
"excess" reference counts beyond those that represent pointers in the
internal libgomp splay-tree data structure. This allows some corner
cases to be handled more gracefully.

2020-07-10  Julian Brown  <julian@codesourcery.com>
	    Thomas Schwinge  <thomas@codesourcery.com>

	libgomp/
	* libgomp.h (struct splay_tree_key_s): Change virtual_refcount to
	dynamic_refcount.
	(struct gomp_device_descr): Remove GOMP_MAP_VARS_OPENACC_ENTER_DATA.
	* oacc-mem.c (acc_map_data): Substitute virtual_refcount for
	dynamic_refcount.
	(acc_unmap_data): Update comment.
	(goacc_map_var_existing, goacc_enter_datum): Adjust for
	dynamic_refcount semantics.
	(goacc_exit_datum_1, goacc_exit_datum): Re-add some error checking.
	Adjust for dynamic_refcount semantics.
	(goacc_enter_data_internal): Implement "present" case of dynamic
	memory-map handling here.  Update "non-present" case for
	dynamic_refcount semantics.
	(goacc_exit_data_internal): Use goacc_exit_datum_1.
	* target.c (gomp_map_vars_internal): Remove
	GOMP_MAP_VARS_OPENACC_ENTER_DATA handling.  Update for dynamic_refcount
	handling.
	(gomp_unmap_vars_internal): Remove virtual_refcount handling.
	(gomp_load_image_to_device): Substitute dynamic_refcount for
	virtual_refcount.
	* testsuite/libgomp.oacc-c-c++-common/pr92843-1.c: Remove XFAILs.
	* testsuite/libgomp.oacc-c-c++-common/refcounting-1.c: New test.
	* testsuite/libgomp.oacc-c-c++-common/refcounting-2.c: New test.
	* testsuite/libgomp.oacc-c-c++-common/struct-3-1-1.c: New test.
	* testsuite/libgomp.oacc-fortran/deep-copy-6.f90: Remove XFAILs and
	trace output.
	* testsuite/libgomp.oacc-fortran/deep-copy-6-no_finalize.F90: Remove
	trace output.
	* testsuite/libgomp.oacc-fortran/dynamic-incr-structural-1.f90: New
	test.
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-4.c:
	Remove stale comment.
	* testsuite/libgomp.oacc-fortran/mdc-refcount-1-1-1.f90: Remove XFAILs.
	* 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-4-1.f90: Adjust XFAIL.

Co-Authored-By: Thomas Schwinge <thomas@codesourcery.com>
(cherry picked from commit 6f5b4b64d25a36f085ab90efc3d54c025a7fff49)

This patch factors out the parts of goacc_enter_datum and
goacc_exit_datum that can be shared with goacc_enter_data_internal
and goacc_exit_data_internal respectively (in the next patch),
without overloading function return values or complicating code paths
unnecessarily.

2020-07-10  Julian Brown  <julian@codesourcery.com>
	    Thomas Schwinge  <thomas@codesourcery.com>

libgomp/
	* oacc-mem.c (goacc_map_var_existing): New function.
	(goacc_enter_datum): Use above function.
	(goacc_exit_datum_1): New function.
	(goacc_exit_datum): Use above function.

Co-Authored-By: Thomas Schwinge <thomas@codesourcery.com>
(cherry picked from commit cb7effde6f36b43d50c8cd7f86eaa05937da7205)

This is a fix for the pointer (or array) size inadvertently being used
for the bias with attach and detach mapping kinds, for both C and C++.

2020-07-09  Julian Brown  <julian@codesourcery.com>
	    Thomas Schwinge  <thomas@codesourcery.com>

gcc/c/
	PR middle-end/95270
	* c-typeck.c (c_finish_omp_clauses): Set OMP_CLAUSE_SIZE (bias) to zero
	for standalone attach/detach clauses.

gcc/cp/
	PR middle-end/95270
	* semantics.c (finish_omp_clauses): Likewise.

include/
	PR middle-end/95270
	* gomp-constants.h (gomp_map_kind): Expand comment for attach/detach
	mapping kinds.

gcc/testsuite/
	PR middle-end/95270
	* c-c++-common/goacc/mdc-1.c: Update expected dump output for zero
	bias.

libgomp/
	PR middle-end/95270
	* testsuite/libgomp.oacc-c-c++-common/pr95270-1.c: New test.
	* testsuite/libgomp.oacc-c-c++-common/pr95270-2.c: New test.

(cherry picked from commit 0d00fe404c162ad0cf922ca8455aa23a74042b63)

Arrange for GOMP_MAP_ATTACH to be grouped together with a preceding
GOMP_MAP_TO_PSET or other "to" data movement clause, except in cases
where an explicit "attach" clause is used.

2020-07-09  Julian Brown  <julian@codesourcery.com>

include/
	* gomp-constants.h (gomp_map_kind): Update comment for GOMP_MAP_TO_PSET.

libgomp/
	* oacc-mem.c (find_group_last): Group data-movement clauses
	(GOMP_MAP_TO_PSET, GOMP_MAP_TO, etc.) together with a subsequent
	GOMP_MAP_ATTACH.  Allow standalone GOMP_MAP_ATTACH also.

(cherry picked from commit 8d2e5026d22b3f30e7df7adfd4ebf4ebc1e77e2d)

Fix a bug with mapping Fortran components which themselves have derived
types in the OpenACC 2.5+ manual deep-copy support.

2020-07-09  Julian Brown  <julian@codesourcery.com>

gcc/fortran/
	* trans-openmp.c (gfc_trans_omp_clauses): Use 'inner' not 'decl' for
	derived type members which themselves have derived types.

gcc/testsuite/
	* gfortran.dg/goacc/mapping-tests-3.f90: New test.
	* gfortran.dg/goacc/mapping-tests-4.f90: New test.

(cherry picked from commit ac8996edb14eef0a15cd0ce850fde2be5e227e69)

The following testcase ICEs since r10-3199.
There is a switch with default label, where the controlling expression has
range just 0..7 and there are case labels for all those 8 values, but
nothing has yet optimized away the default.
Since r10-3199, set_switch_stmt_execution_predicate sets the switch to
default label's edge's predicate to a false predicate and then
compute_bb_predicates propagates the predicates through the cfg, but false
predicates aren't really added.  The caller of compute_bb_predicates
in one place handles NULL bb->aux as false predicate:
      if (fbi.info)
	{
	  if (bb->aux)
	    bb_predicate = *(predicate *) bb->aux;
	  else
	    bb_predicate = false;
	}
      else
	bb_predicate = true;
but then in two further spots that the patch below is changing
it assumes bb->aux must be non-NULL.  Those two spots are guarded by a
condition that is only true if fbi.info is non-NULL, so I think the right
fix is to treat NULL aux as false predicate in those spots too.

2020-07-13  Jakub Jelinek  <jakub@redhat.com>

	PR ipa/96130
	* ipa-fnsummary.c (analyze_function_body): Treat NULL bb->aux
	as false predicate.

	* gcc.dg/torture/pr96130.c: New test.

(cherry picked from commit 776e48e0931db69f158f40e5cb8e15463d879a42)

Avoid printing informational notes when -Wmismatched-tags is suppressed in system headers (PR c++/96063)

Related:
PR c++/96063 - mismatched-tags warnings in stdlib headers

gcc/cp/ChangeLog:

	PR c++/96063
	* parser.c (class_decl_loc_t::diag_mismatched_tags): Print notes only
	if warning_at returns nonzero.

gcc/testsuite/ChangeLog:

	PR c++/96063
	* g++.dg/warn/Wmismatched-tags-7.C: New test.
	* g++.dg/warn/Wmismatched-tags-8.C: New test.

Here's an interesting issue: in this code a ) is missing:

  enum { E = (2 } e;

but we compile the code anyway, and E is set to 0 in build_enumerator,
which is sneaky.

The problem is that cp_parser_enum_specifier parses tentatively, because
when we see the enum keyword, we don't know yet if we'll find an
enum-specifier, opaque-enum-declaration, or elaborated-enum-specifier.

In this test when we call cp_parser_enumerator_list we're still parsing
tentatively, and as a consequence, parens.require_close (parser) in
cp_parser_primary_expression doesn't report any errors.  But we only go
on to parse the enumerator-list after we've seen a {, at which point we
might as well commit -- we know we're dealing with an enum-specifier.

gcc/cp/ChangeLog:

	PR c++/96077
	* parser.c (cp_parser_enum_specifier): Commit to tentative parse
	after we've seen an opening brace.

gcc/testsuite/ChangeLog:

	PR c++/96077
	* g++.dg/parse/enum14.C: New test.

(cherry picked from commit 4fd124a23664c712f1bb1a7e91fa23fe83d72c0b)

The testcase was errorneously accessing the global variable via a
type that might require bigger alignment than provided.  Fix that
via an appropriate attribute.

2020-07-13  Richard Biener  <rguenther@suse.de>

	PR testsuite/96180
	* gcc.dg/torture/pr96133.c: Align global variable.

(cherry picked from commit 7a4770f0394751860ee54520b23007938907ac33)

The store to the whole of each volatile object was picked apart
like there had been an individual assignment to each of the
fields.  Reads were added as part of that; see PR for details.
The reads from volatile memory were a clear bug; individual
stores questionable.  A separate patch clarifies the docs.

gcc:

2020-07-09  Richard Biener  <rguenther@suse.de>

	PR middle-end/94600
	* expr.c (expand_constructor): Make a temporary also if we're
	storing to volatile memory.

gcc/testsuite:

2020-07-09  Hans-Peter Nilsson  <hp@axis.com>

	PR middle-end/94600
	* gcc.dg/pr94600-1.c, gcc.dg/pr94600-2.c, gcc.dg/pr94600-3.c,
	gcc.dg/pr94600-4.c, gcc.dg/pr94600-5.c, gcc.dg/pr94600-6.c,
	gcc.dg/pr94600-7.c, gcc.dg/pr94600-8.c: New tests.

(cherry picked from commit a4aca1edaf37d43b2b7e9111825837a7a317b1b0)

The following testcase ICEs, because during the cfg cleanup, we see:
  switch (i$e_11) <default: <L12> [33.33%], case -3: <lab2> [33.33%], case 0: <L10> [33.33%], case 2: <lab2> [33.33%]>
...
lab2:
  __builtin_unreachable ();
where lab2 is FORCED_LABEL.  The way it works, we go through the case labels
and when we reach the first one that points to gimple_seq_unreachable*
basic block, we remove the edge (if any) from the switch bb to the bb
containing the label and bbs reachable only through that edge we've just
removed.  Once we do that, we must throw away all other cases that use
the same label (or some other labels from the same bb we've removed the edge
to and the bb).  To avoid quadratic behavior, this is not done by walking
all remaining cases immediately before removing, but only when processing
them later.
For normal labels this works, fine, if the label is in a deleted bb, it will
have NULL label_to_block and we handle that case, or, if the unreachable bb
has some other edge to it, only the edge will be removed and not the bb,
and again, find_edge will not find the edge and we only remove the case.
And if a label would be to some other block, that other block wouldn't have
been removed earlier because there would be still an edge from the switch
block.
Now, FORCED_LABEL (and I think DECL_NONLOCAL too) break this, because
those labels aren't removed, but instead moved to some surrounding basic
block.  So, when we later process those, when their gimple_seq_unreachable*
basic block is removed, label_to_block will return some unrelated block
(in the testcase the switch bb), so we decide to keep the case which doesn't
seem to be unreachable, but we don't really have an edge from the switch
block to the block the label got moved to.

I thought first about punting in gimple_seq_unreachable* on
FORCED_LABEL/DECL_NONLOCAL labels, but that might penalize even code that
doesn't care, so this instead just makes sure that for
FORCED_LABEL/DECL_NONLOCAL labels that are being removed (and thus moved
randomly) we remember in a hash_set the fact that those labels should be
treated as removed for the purpose of the optimization, and later on
handle those labels that way.

2020-07-02  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/95857
	* tree-cfg.c (group_case_labels_stmt): When removing an unreachable
	base_bb, remember all forced and non-local labels on it and later
	treat those as if they have NULL label_to_block.  Formatting fix.
	Fix a comment typo.

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

(cherry picked from commit 00f24f56732861d09a9716fa5b6b8a96c2289143)

gcc/ChangeLog:

	PR target/95581
	* config/rs6000/rs6000-call.c: Add new type v16qi_ftype_pcvoid.
	(altivec_init_builtins) Change __builtin_altivec_mask_for_load to use
	v16qi_ftype_pcvoid with correct number of parameters.

(cherry picked from commit c6b7ba5de624f2a17d799bac5ff017cd065ce035)