There's no point in using value '-3', and even though not directly related,
value '-1' does match 'GOMP_DEVICE_ICV'.

	libgomp/
	* config/accel/openacc.f90 (acc_device_current): Set to '-1'.
	* openacc.f90 (acc_device_current): Likewise.
	* openacc.h (acc_device_current): Likewise.
	* openacc_lib.h (acc_device_current): Likewise.

Fix-up for commit d228ee80 "re PR
bootstrap/92314 (missing omp-device-properties', needed by
's-omp-device-properties-h')".

	gcc/
	* configure.ac <$enable_offload_targets>: Do parsing as done
	elsewhere.
	* configure: Regenerate.

Fix-up for commit 955cd057 "Add
gcc/config/gcn/t-omp-device for OpenMP declare variant kind/arch/isa".

With AMD GCN offloading configured, I'm seeing occasional GCC build hangs.
I've now captured and analyzed one of them:

    $ ps -f
    UID        PID  PPID  C STIME TTY          TIME CMD
    [...]
    tschwing  5113  4508  0 20:24 pts/5    00:00:00 /bin/sh -c rm -f tmp-omp-device-properties.h; \ for kind in kind arch isa; do \   echo 'const char omp_offload_device_'${kind}'[] = ' \     >> tmp-omp-device-properties.h; \   for prop in no
    tschwing  5126  5113  0 20:24 pts/5    00:00:00 sed -n s/^kind: //p
    tschwing  5127  5113  0 20:24 pts/5    00:00:00 sed s/[[:blank:]]/ /g;s/  */ /g;s/^ //;s/ $//;s/ /\\0/g;s/^/"/;s/$/\\0\\0"/
    [...]
    $ pstree -p $$
    [...]---sh(5113)-+-sed(5126)
                     `-sed(5127)
    $ ls -lrt build-gcc/gcc/*omp-device*
    -rw-r--r-- 1 tschwing eeg  39 Apr 23 20:24 build-gcc/gcc/omp-device-properties-nvptx
    -rw-r--r-- 1 tschwing eeg 634 Apr 23 20:24 build-gcc/gcc/omp-device-properties-i386
    -rw-r--r-- 1 tschwing eeg  58 Apr 23 20:24 build-gcc/gcc/tmp-omp-device-properties.h

Notably missing is the 'omp-device-properties-gcn' file...

    $ grep ^ build-gcc/gcc/*omp-device*
    build-gcc/gcc/omp-device-properties-i386:kind: cpu
    build-gcc/gcc/omp-device-properties-i386:arch: x86 x86_64 i386 i486 i586 i686 ia32
    build-gcc/gcc/omp-device-properties-i386:isa: sse4 cx16 [...]
    build-gcc/gcc/omp-device-properties-nvptx:kind: gpu
    build-gcc/gcc/omp-device-properties-nvptx:arch: nvptx
    build-gcc/gcc/omp-device-properties-nvptx:isa: sm_30 sm_35
    build-gcc/gcc/tmp-omp-device-properties.h:const char omp_offload_device_kind[] =
    build-gcc/gcc/tmp-omp-device-properties.h:"amdgcn-amdhsa\0"

..., which we here seem to be intending to fill into
'tmp-omp-device-properties.h'.

    $ grep ^omp_device_properties\ = build-gcc/gcc/Makefile
    omp_device_properties =  amdgcn-amdhsa= nvptx-none=omp-device-properties-nvptx x86_64-intelmicemul-linux-gnu=omp-device-properties-i386

Given the 's-omp-device-properties-h' Makefile rule, indeed there is an
unescaped '$${props}', which is meant to be the filename following the equals
sign -- but there is none for 'amdgcn-amdhsa=', so this tries to read from
'stdin'!

The real problem of course is elsewhere.

	gcc/
	* configure.ac <$enable_offload_targets>: 'amdgcn' is 'gcn'.
	* configure: Regenerate.

... given that the GCN target did away with the constant 'vec_select'
restriction.

	gcc/
	PR target/94279
	* rtlanal.c (set_noop_p): Handle non-constant selectors.

In libgomp offloading testing, this resolves all the 'ld: error: undefined
symbol: __gxx_personality_v0' FAILs.

	gcc/
	PR target/94282
	* common/config/gcn/gcn-common.c (gcn_except_unwind_info): New
	function.
	(TARGET_EXCEPT_UNWIND_INFO): Define.
	libgomp/
	PR target/94282
	* testsuite/libgomp.c-c++-common/function-not-offloaded.c: Remove
	'dg-allow-blank-lines-in-output'.

Building (for offloading) a '--target=amdgcn-amdhsa' GCC with
'--enable-checking=yes,extra,rtl' fails:

    during RTL pass: split2
    [...]/source-gcc/libgcc/libgcc2.c: In function '__absvdi2':
    [...]/source-gcc/libgcc/libgcc2.c:271:1: internal compiler error: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1923
      271 | }
	  | ^
    0x565847 ???
	    [...]/source-gcc/gcc/rtl.c:881
    0x59a8a4 ???
	    [...]/source-gcc/gcc/rtl.h:1923
    0x12e3a5c ???
	    [...]/source-gcc/gcc/config/gcn/gcn.md:631
    [...]
    Makefile:501: recipe for target '_absvdi2.o' failed
    make[4]: *** [_absvdi2.o] Error 1
    make[4]: Leaving directory '[...]/build-gcc-offload-amdgcn-amdhsa/amdgcn-amdhsa/gfx900/libgcc'

	gcc/
	PR target/94248
	* config/gcn/gcn.md (*mov<mode>_insn): Use
	'reg_overlap_mentioned_p' to check for overlap.

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

... which hasn't been ported/fails to build when using newlib (with GCC commit
b73f6902 sources, and newlib commit
6d79e0a58866548f435527798fbd4a6849d05bc7, tag: newlib-3.3.0 sources):

    In file included from [...]/build-gcc-offload-amdgcn-amdhsa/amdgcn-amdhsa/libstdc++-v3/include/csetjmp:42,
                     from [...]/source-gcc/libstdc++-v3/include/precompiled/stdc++.h:42:
    [...]/source-gcc/newlib/libc/include/setjmp.h:15:6: error: variable or field 'longjmp' declared void
       15 | void longjmp (jmp_buf __jmpb, int __retval)
          |      ^~~~~~~
    [...]
    Makefile:1824: recipe for target 'amdgcn-amdhsa/bits/stdc++.h.gch/O2ggnu++0x.gch' failed
    make[3]: *** [amdgcn-amdhsa/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1

	PR target/92713
	* configure.ac ["${ENABLE_LIBSTDCXX}" = "default" && amdgcn*-*-*]
	(noconfigdirs): Add 'target-libstdc++-v3'.
	* configure: Regenerate.

..., per OpenACC 3.0, A.1.2. "AMD GPU Targets".

This complements commit 6687d13a "Rename
acc_device_gcn to acc_device_radeon".

	libgomp/
	* oacc-init.c (get_openacc_name): Handle 'gcn'.
	* testsuite/lib/libgomp.exp
	(offload_target_to_openacc_device_type) [amdgcn*]: Return
	'radeon'.  Adjust all users.
	(check_effective_target_openacc_amdgcn_accel_present): Rename
	to...
	(check_effective_target_openacc_radeon_accel_present): ... this.
	Adjust all users.
	(check_effective_target_openacc_amdgcn_accel_selected): Rename to...
	(check_effective_target_openacc_radeon_accel_selected): ... this.
	Adjust all users.

Fix-up for commit a2c26c50 (r278046) "Fortran]
Support absent optional args with use_device_{ptr,addr}".

	libgomp/
	* testsuite/libgomp.fortran/use_device_ptr-optional-2.f90: Add
	'dg-do run'.

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

	PR target/94706
	* config/ia64/ia64.c (hfa_element_mode): Use DECL_FIELD_ABI_IGNORED
	instead of cxx17_empty_base_field_p.

c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout and [[no_unique_address]] handling [PR94707]

As reported by Iain and David, powerpc-darwin and powerpc-aix* have C++14
vs. C++17 ABI incompatibilities which are not fixed by mere adding of
cxx17_empty_base_field_p calls.  Unlike the issues that were seen on other
targets where the artificial empty base field affected function argument
passing or returning of values, on these two targets the difference is
during class layout, not afterwards (e.g.
struct empty_base {};
struct S : public empty_base { unsigned long long l[2]; };
will have different __alignof__ (S) between C++14 and C++17 (or possibly
with double instead of unsigned long long too)).

I've tried:
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { float a, b, c, d; };
struct B : public X { float a, b, c, d; };
struct C : public Y { float a, b, c, d; };
struct D : public Z { float a, b, c, d; };
struct E : public U { float a, b, c, d; };
struct F { [[no_unique_address]] X x; float a, b, c, d; };
struct G { [[no_unique_address]] Y y; float a, b, c, d; };
struct H { [[no_unique_address]] Z z; float a, b, c, d; };
struct I { [[no_unique_address]] U u; float a, b, c, d; };
struct J { float a, b; [[no_unique_address]] X x; float c, d; };
struct K { float a, b; [[no_unique_address]] Y y; float c, d; };
struct L { float a, b; [[no_unique_address]] Z z; float c, d; };
struct M { float a, b; [[no_unique_address]] U u; float c, d; };
 #define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s (s); return 0; }
T (A, a)
T (B, b)
T (C, c)
T (D, d)
T (E, e)
T (F, f)
T (G, g)
T (H, h)
T (I, i)
T (J, j)
T (K, k)
T (L, l)
T (M, m)
testcase on powerpc64-linux.  Results:
G++ 9 -std=c++14                A, B, C passed in fprs, the rest in gprs
G++ 9 -std=c++17                A passed in fprs, the rest in gprs
current trunk -std=c++14 & 17   A, B, C passed in fprs, the rest in gprs
patched trunk -std=c++14 & 17   A, B, C, F, G, J, K passed in fprs, the rest in gprs
clang++ [*] -std=c++14 & 17     A, B, C, F, G, J, K passed in fprs, the rest in gprs
[*] clang version 11.0.0 (git@github.com:llvm/llvm-project.git 5c352e69e76a26e4eda075e20aa6a9bb7686042c)

Is that what we want?  I think it matches the stated intent of P0840R2 or
what Jason/Jonathan said, and doing something different like e.g. not
treating C, G and K as homogenous because of the int : 0 in empty bases
or in zero sized [[no_unique_address] fields would be quite hard to
implement (because for C++14 the FIELD_DECL just isn't there).

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

	PR target/94707
	* tree-core.h (tree_decl_common): Note decl_flag_0 used for
	DECL_FIELD_ABI_IGNORED.
	* tree.h (DECL_FIELD_ABI_IGNORED): Define.
	* calls.h (cxx17_empty_base_field_p): Change into a temporary
	macro, check DECL_FIELD_ABI_IGNORED flag with no "no_unique_address"
	attribute.
	* calls.c (cxx17_empty_base_field_p): Remove.
	* tree-streamer-out.c (pack_ts_decl_common_value_fields): Handle
	DECL_FIELD_ABI_IGNORED.
	* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Likewise.
	* lto-streamer-out.c (hash_tree): Likewise.
	* config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Rename
	cxx17_empty_base_seen to empty_base_seen, change type to int *,
	adjust recursive calls, use DECL_FIELD_ABI_IGNORED instead of
	cxx17_empty_base_field_p, if "no_unique_address" attribute is
	present, propagate that to the caller too.
	(rs6000_discover_homogeneous_aggregate): Adjust
	rs6000_aggregate_candidate caller, emit different diagnostics
	when c++17 empty base fields are present and when empty
	[[no_unique_address]] fields are present.
	* config/rs6000/rs6000.c (rs6000_special_round_type_align,
	darwin_rs6000_special_round_type_align): Skip DECL_FIELD_ABI_IGNORED
	fields.

	* class.c (build_base_field): Set DECL_FIELD_ABI_IGNORED on C++17 empty
	base artificial FIELD_DECLs.
	(layout_class_type): Set DECL_FIELD_ABI_IGNORED on empty class
	field_poverlapping_p FIELD_DECLs.

	* lto-common.c (compare_tree_sccs_1): Handle DECL_FIELD_ABI_IGNORED.

	* g++.target/powerpc/pr94707-1.C: New test.
	* g++.target/powerpc/pr94707-2.C: New test.
	* g++.target/powerpc/pr94707-3.C: New test.
	* g++.target/powerpc/pr94707-4.C: New test.
	* g++.target/powerpc/pr94707-5.C: New test.
	* g++.target/powerpc/pr94707-4.C: New test.

This fixes a regression when canonicalizing refs for LIM PR84362.
This possibly unshares and rewrites the refs in the internal data
and thus pointer equality no longer works in ref_always_accessed
computation.

2020-04-29  Richard Biener  <rguenther@suse.de>

	* tree-ssa-loop-im.c (ref_always_accessed::operator ()):
	Just check whether the stmt stores.

As observed in PR94719, an inherited constructor for an instantiation of
a constructor template confusingly has as its DECL_INHERITED_CTOR the
TEMPLATE_DECL of the constructor template rather than the particular
instantiation of the template.

This means two inherited constructors for two different instantiations
of the same constructor template have the same DECL_INHERITED_CTOR.  And
since in satisfy_declaration_constraints our decl satisfaction cache is
keyed off of the result of strip_inheriting_ctors, we may end up
conflating the satisfaction values of the two inherited constructors'
constraints.

This patch fixes this issue by using the original tree, not the result
of strip_inheriting_ctors, as the key to the decl satisfaction cache.

gcc/cp/ChangeLog:

	PR c++/94819
	* constraint.cc (satisfy_declaration_constraints): Use saved_t
	instead of t as the key to decl_satisfied_cache.

gcc/testsuite/ChangeLog:

	PR c++/94819
	* g++.dg/cpp2a/concepts-inherit-ctor10.C: New test.
	* g++.dg/cpp2a/concepts-inherit-ctor11.C: New test.

When printing the substituted parameter list of a requires-expression as
part of the "in requirements with ..." context line during concepts
diagnostics, we weren't considering that substitution into a parameter
pack can yield zero or multiple parameters.

This patch changes the way we print the parameter list of a
requires-expression in print_requires_expression_info.  We now print the
dependent form of the parameter list (along with its template parameter
mapping) instead of printing its substituted form.  Besides being an
improvement in its own, this also sidesteps the substitution issue in the
PR altogether.

gcc/cp/ChangeLog:

	PR c++/94808
	* error.c (print_requires_expression_info): Print the dependent
	form of the parameter list with its template parameter mapping,
	rather than printing the substituted form.

gcc/testsuite/ChangeLog:

	PR c++/94808
	* g++.dg/concepts/diagnostic12.C: New test.
	* g++.dg/concepts/diagnostic5.C: Adjust dg-message.

Remove the non-standard __cpp_lib_allocator_is_always_equal macro and
add the missing macros for P1032R1.

	PR libstdc++/91480
	* include/bits/allocator.h (__cpp_lib_allocator_is_always_equal):
	Remove non-standard macro.
	* include/bits/stl_iterator.h (__cpp_lib_constexpr_iterator): Define
	to indicate P1032R1 support.
	* include/bits/stl_pair.h (__cpp_lib_constexpr_utility): Likewise.
	* include/std/string_view (__cpp_lib_constexpr_string_view): Likewise.
	* include/std/tuple (__cpp_lib_constexpr_tuple): Likewise.
	* include/std/version (__cpp_lib_allocator_is_always_equal): Remove.
	(__cpp_lib_constexpr_iterator, __cpp_lib_constexpr_string_view)
	(__cpp_lib_constexpr_tuple, __cpp_lib_constexpr_utility): Define.
	* testsuite/20_util/function_objects/constexpr_searcher.cc: Check
	feature test macro.
	* testsuite/20_util/tuple/cons/constexpr_allocator_arg_t.cc: Likewise.
	* testsuite/21_strings/basic_string_view/operations/copy/char/
	constexpr.cc: Likewise.
	* testsuite/24_iterators/insert_iterator/constexpr.cc: Likewise.

By trying to reuse the existing std::_Construct function as a wrapper
for std::construct_at I introduced regressions, because changing
std::_Construct to return non-void made it ill-formed for array types.

The solution is to revert _Construct to its former state, and change
allocator_traits::construct to explicitly call construct_at instead.
This decouples all the existing callers of _Construct from the new
construct_at requirements.

	PR libstdc++/94831
	* include/bits/alloc_traits.h (_S_construct): Restore placement
	new-expression for C++11/14/17 and call std::construct_at directly
	for C++20.
	* include/bits/stl_construct.h (_Construct): Revert to non-constexpr
	function returning void.
	* testsuite/20_util/specialized_algorithms/
	uninitialized_value_construct/94831.cc: New test.
	* testsuite/23_containers/vector/cons/94831.cc: New test.

The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going
through the motions, but not storing the result in the given
operands[0]; it rather modifies operands[0] without effect.  It also
creates a DImode pseudo that it doesn't use, overwriting subregs
instead.

The patch below fixes all of these, the indentation and a typo.


I'm concerned about several issues in the mffsl testcase.  First, I
don't see that comparing the values as doubles rather than as long
longs is desirable.  These are FPSCR bitfields, not FP numbers.  I
understand mffs et al use double because they output to FP registers,
and the bit patterns are subnormal FP numbers, so it works, but given
the need for bit masking of at least one side, I'm changing the
compare to long longs.

Another issue with the test is that, if the compare fails, it calls
mffsl again to print the value, as if it would yield the same result.
But part of the FPSCR that mffsl (emulated with mffs or not) copies to
the output FP register is the FPCC, so the fcmpu used to compare the
result of the first mffsl will modify FPSCR and thus the result of the
second mffsl call.  After changing the compare, this is no longer the
case, but I still think it's better to make absolutely sure what we
print is what we compared.

Yet another issue is that the test assumed the mffs bits that are not
to be extracted by mffsl to be already zero, instead of masking them
out explicitly.  This is not about the mffs emulation in the mffsl
implementation, but about the mffs use in the test proper.  The bits
appear to be zero indeed, as the bits left out are for sticky
exceptions, but there are reserved parts of FPSCR that might turn out
to be set in the future, so we're better off masking them out
explicitly, otherwise those bits could cause the compare to fail.

If some future mffsl is changed so that it copies additional nonzero
bits, the test will fail, and then we'll have a chance to adjust it
and the emulation.


for  gcc/ChangeLog

	PR target/94812
	* gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to
	output operand in emulation.  Don't overwrite pseudos.

for  gcc/testsuite/ChangeLog

	PR target/94812
	* gcc.target/powerpc/test_mffsl.c: Call mffsl only once.
	Reinterpret the doubles as long longs for compares.  Mask out
	mffs bits that are not expected from mffsl.

This implements the proposed resolution of LWG 3433, which fixes
subrange::advance when called with a negative argument.

libstdc++-v3/ChangeLog:

	LWG 3433 subrange::advance(n) has UB when n < 0
	* include/std/ranges (subrange::prev): Fix typo.
	(subrange::advance): Handle a negative argument as per the proposed
	resolution of LWG 3433.
	* testsuite/std/ranges/subrange/lwg3433.cc: New test.

Fix some testsuite failures for H8/SX multilibs where short branches where used when long branches were necessary.

	* config/h8300/h8300.md (H8/SX mult patterns): All H8/SX specific
	multiply patterns are 4 bytes long.

Multilibs should not have been split up as two logically different CPU,
so at configure time, powerpc64 was being detected, but none of the
32-bit support files were being compiled in.

libphobos/ChangeLog:

	PR d/94825
	* configure: Regenerate.
	* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Add both
	switchcontext.S and callwithstack.S if DRUNTIME_CPU_POWERPC.
	* libdruntime/Makefile.in: Regenerate.
	* libdruntime/config/powerpc/switchcontext.S: Add !__PPC64__ guards.
	* libdruntime/config/powerpc64/callwithstack.S: Add __PPC64__ guards.
	* m4/druntime/cpu.m4 (DRUNTIME_CPU_SOURCES): Define DRUNTIME_CPU_POWER
	for all powerpc biarchs.  Remove DRUNTIME_CPU_POWER64 conditional.

My last patch rejected a namespace-scope declaration of the
implicitly-declared friend operator== before the class, but redeclaring it
after the class should be OK.

gcc/cp/ChangeLog
2020-04-28  Jason Merrill  <jason@redhat.com>

	PR c++/94583
	* decl.c (use_eh_spec_block): Check nothrow type after
	DECL_DEFAULTED_FN.
	* pt.c (maybe_instantiate_noexcept): Call synthesize_method for
	DECL_MAYBE_DELETED fns here.
	* decl2.c (mark_used): Not here.
	* method.c (get_defaulted_eh_spec): Reject DECL_MAYBE_DELETED here.

PR analyzer/94816 reports an ICE when attempting to copy a struct
containing a field for which add_region_for_type for fails (on
an OFFSET_TYPE): the region for the src field comes from
make_region_for_unexpected_tree_code which gives it a NULL type, and
then the copy calls add_region_for_type which unconditionally
dereferences the NULL type.

This patch fixes the ICE by checking for NULL types in
add_region_for_type.

gcc/analyzer/ChangeLog:
	PR analyzer/94816
	* engine.cc (impl_region_model_context::on_unexpected_tree_code):
	Handle NULL tree.
	* region-model.cc (region_model::add_region_for_type): Handle
	NULL type.
	* region-model.h
	(test_region_model_context::on_unexpected_tree_code): Handle NULL
	tree.

gcc/testsuite/ChangeLog:
	PR analyzer/94816
	* g++.dg/analyzer/pr94816.C: New test.

Turns out for consistency with LLVM the +nofp option shouldn't remove ALL of FP and MVE, just the FP part of MVE.
This requires more surgery with feature bits so for GCC 10 I'd rather just not support +nofp for -mcpu=cortex-m55
and implement it properly for GCC 11.

2020-04-28  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

	* config/arm/arm-cpus.in (cortex-m55): Remove +nofp option.
	* doc/invoke.texi (Arm Options): Remove -mcpu=cortex-m55 from +nofp option.

In C++14, an empty class deriving from an empty base is not an
aggregate, while in C++17 it is.  In order to implement this, GCC adds
an artificial field to such classes.

This artificial field has no mapping to Fundamental Data Types in the
Arm PCS ABI and hence should not count towards determining whether an
object can be passed using the vector registers as per section
"7.1.2 Procedure Calling" in the arm PCS
https://developer.arm.com/docs/ihi0042/latest?_ga=2.60211309.1506853196.1533541889-405231439.1528186050

This patch avoids counting this artificial field in
aapcs_vfp_sub_candidate, and hence calculates whether such objects
should be passed in vector registers in the same manner as C++14 (where
the artificial field does not exist).

Before this change, the test below would pass the arguments to `f` in
general registers.  After this change, the test passes the arguments to
`f` using the vector registers.

The new behaviour matches the behaviour of `armclang`, and also matches
the GCC behaviour when run with `-std=gnu++14`.

> gcc -std=gnu++17 -march=armv8-a+simd -mfloat-abi=hard test.cpp

``` test.cpp
struct base {};

struct pair : base
{
  float first;
  float second;
  pair (float f, float s) : first(f), second(s) {}
};

void f (pair);
int main()
{
  f({3.14, 666});
  return 1;
}
```

We add a `-Wpsabi` warning to catch cases where this fix has changed the ABI for
some functions.  Unfortunately this warning is not emitted twice for multiple
calls to the same function, but I feel this is not much of a problem and can be
fixed later if needs be.

(i.e. if `main` called `f` twice in a row we only emit a diagnostic for the
first).

Testing:
    Bootstrapped and regression tested on arm-linux.
    This change fixes the struct-layout-1 tests Jakub added
    https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544204.html
    Regression tested on arm-none-eabi.

gcc/ChangeLog:

2020-04-28  Matthew Malcomson  <matthew.malcomson@arm.com>
	    Jakub Jelinek  <jakub@redhat.com>

	PR target/94711
	* config/arm/arm.c (aapcs_vfp_sub_candidate): Account for C++17 empty
	base class artificial fields.
	(aapcs_vfp_is_call_or_return_candidate): Warn when PCS ABI
	decision is different after this fix.

From what I can tell -Wanalyzer-use-of-uninitialized-value has not
yet found a true diagnostic in real-world code, and seems to be
particularly susceptible to false positives.  These relate to bugs in
the region_model code.

For GCC 10 it seems best to remove this warning, which this patch does.
Internally it also removes POISON_KIND_UNINIT.

I'm working on a rewrite of the region_model code for GCC 11 that I
hope will fix these issues, and allow this warning to be reintroduced.

gcc/analyzer/ChangeLog:
	PR analyzer/94447
	PR analyzer/94639
	PR analyzer/94732
	PR analyzer/94754
	* analyzer.opt (Wanalyzer-use-of-uninitialized-value): Delete.
	* program-state.cc (selftest::test_program_state_dumping): Update
	expected dump result for removal of "uninit".
	* region-model.cc (poison_kind_to_str): Delete POISON_KIND_UNINIT
	case.
	(root_region::ensure_stack_region): Initialize stack with null
	svalue_id rather than with a typeless POISON_KIND_UNINIT value.
	(root_region::ensure_heap_region): Likewise for the heap.
	(region_model::dump_summary_of_rep_path_vars): Remove
	summarization of uninit values.
	(region_model::validate): Remove check that the stack has a
	POISON_KIND_UNINIT value.
	(poisoned_value_diagnostic::emit): Remove POISON_KIND_UNINIT
	case.
	(poisoned_value_diagnostic::describe_final_event): Likewise.
	(selftest::test_dump): Update expected dump result for removal of
	"uninit".
	(selftest::test_svalue_equality): Remove "uninit" and "freed".
	* region-model.h (enum poison_kind): Remove POISON_KIND_UNINIT.

gcc/ChangeLog:
	PR analyzer/94447
	PR analyzer/94639
	PR analyzer/94732
	PR analyzer/94754
	* doc/invoke.texi (Static Analyzer Options): Remove
	-Wanalyzer-use-of-uninitialized-value.
	(-Wno-analyzer-use-of-uninitialized-value): Remove item.

gcc/testsuite/ChangeLog:
	PR analyzer/94447
	PR analyzer/94639
	PR analyzer/94732
	PR analyzer/94754
	* gcc.dg/analyzer/data-model-1.c: Mark "use of uninitialized
	value" warnings as xfail for now.
	* gcc.dg/analyzer/data-model-5b.c: Remove uninitialized warning.
	* gcc.dg/analyzer/pr94099.c: Mark "uninitialized" warning as xfail
	for now.
	* gcc.dg/analyzer/pr94447.c: New test.
	* gcc.dg/analyzer/pr94639.c: New test.
	* gcc.dg/analyzer/pr94732.c: New test.
	* gcc.dg/analyzer/pr94754.c: New test.
	* gcc.dg/analyzer/zlib-6.c: Mark "uninitialized" warning as xfail
	for now.

GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host
has Intel CET enabled by introducing an Intel CET violation on purpose.
To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first.
-fcf-protection=none is added to avoid false negative when -fcf-protection
is enabled by default.

config/

	PR bootstrap/94739
	* cet.m4 (GCC_CET_HOST_FLAGS): Add -fcf-protection=none to
	-Wl,-z,ibt,-z,shstk.  Check whether -fcf-protection=none
	-Wl,-z,ibt,-z,shstk works first.

libiberty/

	PR bootstrap/94739
	* configure: Regenerated.

lto-plugin/

	PR bootstrap/94739
	* configure: Regenerated.

On the following testcase, match.pd during GENERIC folding
changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y),
but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on
the call.  There is the process_call_operands function that non-internal
call creation calls and it is usable for internal calls too,
e.g. TREE_SIDE_EFFECTS is derived from checking whether the
call has side-effects (non-ECF_{CONST,PURE}; we have those for internal
calls) and from whether any of the arguments has TREE_SIDE_EFFECTS.

2020-04-28  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/94809
	* tree.c (build_call_expr_internal_loc_array): Call
	process_call_operands.

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

Here is the patch introducing thunderx3t110 machine model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for
mcpu and mtune flags. Added the TX3 tuning table and cost
model tables.

Added the new chip name to the documentation. Fixed copyright
names and dates.

Lowering the chip capabilities to v8.3 to be on the safe side.

Bootstrapped on AArch64.

2020-04-27 Anton Youdkevitch <anton.youdkevitch@bell-sw.com>

        * config/aarch64/aarch64-cores.def: Add the chip name.
        * config/aarch64/aarch64-tune.md: Regenerated.
        * config/aarch64/aarch64.c: Add tuning table for the chip.
        * gcc/config/aarch64/aarch64-cost-tables.h: Add cost tables.
        * config/aarch64/thunderx3t110.md: New file: add the new
        machine model for the scheduler
        * config/aarch64/aarch64.md: Include the new model.
        * doc/invoke.texi: Add the new name to the list

> We probably have to look into providing a -Wpsabi warning as well.

So like this?

2020-04-28  Jakub Jelinek  <jakub@redhat.com>

	PR target/94704
	* config/s390/s390.c (s390_function_arg_vector,
	s390_function_arg_float): Emit -Wpsabi diagnostics if the ABI changed.

The previous patch for this PR handled separate comparisons.
However, as arm targets show, the same fix is needed when
handling comparisons embedded in a VEC_COND_EXPR.

Here too, the problem is that vect_get_constant_vectors will
calculate its own vector type, using truth_type_for on the
STMT_VINFO_VECTYPE, and the vectoriable_* routines need to be
consistent with that.

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

gcc/
	PR tree-optimization/94727
	* tree-vect-stmts.c (vect_is_simple_cond): If both comparison
	operands are invariant booleans, use the mask type associated with the
	STMT_VINFO_VECTYPE.  Use !slp_node instead of !vectype to exclude SLP.
	(vectorizable_condition): Pass vectype unconditionally to
	vect_is_simple_cond.

We changed the argument passed to the promise parameter preview
to match a reference to *this.  However to be consistent with the
other ports, we do need to match the reference transformation in
the traits lookup and the promise allocator lookup.

gcc/cp/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94760
	* coroutines.cc (instantiate_coro_traits): Pass a reference to
	object type rather than a pointer type for 'this', for method
	coroutines.
	(struct param_info): Add a field to hold that the parm is a lambda
	closure pointer.
	(morph_fn_to_coro): Check for lambda closure pointers in the
	args.  Use a reference to *this when building the args list for the
	promise allocator lookup.

gcc/testsuite/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94760
	* g++.dg/coroutines/pr94760-mismatched-traits-and-promise-prev.C:
	New test.

From the standard:

The header <coroutine> defines the primary template coroutine_traits
such that if ArgTypes is a parameter pack of types and if the
qualified-id R::promise_type is valid and denotes a type, then
coroutine_traits<R,ArgTypes...> has the following publicly accessible
member:
     using promise_type = typename R::promise_type;

this should not prevent more specialised cases and  the following
code should be accepted, but is currently rejected with:

'error: coroutine return type ‘void’ is not a class'

This is because the check for non-class-ness of the return value was
in the wrong place; it needs to be carried out in a SFINAE context.

The following patch removes the restriction in the traits template
instantiation and allows for the case that the ramp function could
return void.

The <coroutine> header is amended to implement the required
functionality.

gcc/cp/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94759
	* coroutines.cc (coro_promise_type_found_p): Do not
	exclude non-classes here (this needs to be handled in the
	coroutine header).
	(morph_fn_to_coro):  Allow for the case where the coroutine
	returns void.

gcc/testsuite/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94759
	* g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Adjust for
	updated error messages.
	* g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise.
	* g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise.
	* g++.dg/coroutines/coro-missing-promise.C: Likewise.
	* g++.dg/coroutines/pr93458-5-bad-coro-type.C: Liekwise.
	* g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C: New test.

libstdc++-v3/ChangeLog:

2020-04-28  Jonathan Wakely  <jwakely@redhat.com>
	    Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94759
	* include/std/coroutine: Implement handing for non-
	class coroutine return types.

Structured binding makes use of the DECL_VALUE_EXPR fields
in local variables.  We need to recognise these and only amend
the expression values, retaining the 'alias' value intact.

gcc/cp/ChangeLog:

2020-04-27  Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94701
	* coroutines.cc (struct local_var_info): Add fields for static
	variables and those with DECL_VALUE_EXPR redirection.
	(transform_local_var_uses):  Skip past typedefs and static vars
	and then account for redirected variables.
	(register_local_var_uses): Likewise.

gcc/testsuite/ChangeLog:

2020-04-27  Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94701
	* g++.dg/coroutines/torture/local-var-06-structured-binding.C: New test.

2020-04-27  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/93956
	PR fortran/94788
	* expr.c (gfc_check_pointer_assign): Revert patch for PR 93956.
	* interface.c: Likewise.

2020-04-27  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/93956
	PR fortran/94788
	* gfortran.dg/pointer_assign_13.f90: Remove.

Merge upstream druntime 47688279.

Reviewed-on: https://github.com/dlang/druntime/pull/3073

Fixes: PR d/90718
Fixes: PR d/90719

libphobos/ChangeLog:

	* libdruntime/Makefile.am (DRUNTIME_DSOURCES_LINUX): Remove
	core/sys/linux/sys/netinet/tcp.d.
	* libdruntime/Makefile.in: Regenerate.

This function, because it is sometimes called even outside of function
bodies, uses create_tmp_var_raw rather than create_tmp_var.  But in order
for that to work, when first referenced, the VAR_DECLs need to appear in a
TARGET_EXPR so that during gimplification the var gets the right
DECL_CONTEXT and is added to local decls.  Without that, e.g. tree-nested.c
ICEs on those.

2020-04-27  Jakub Jelinek  <jakub@redhat.com>

	PR target/94780
	* config/i386/i386.c (ix86_atomic_assign_expand_fenv): Use
	TARGET_EXPR instead of MODIFY_EXPR for first assignment to
	sw_var, exceptions_var, mxcsr_orig_var and mxcsr_mod_var.

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

We previously happened to accept this testcase, but never actually did
anything useful with the attribute.  The patch for PR86379 stopped using
TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set,
so the language-independent decl_attributes started crashing on it.

GNU attributes are more flexible in their placement than C++11 attributes,
so if we encounter a dependent GNU attribute that syntactically appertains
to a type rather than the declaration as a whole, move it to the
declaration; that's almost certainly what the user meant, anyway.

gcc/cp/ChangeLog
2020-04-27  Jason Merrill  <jason@redhat.com>

	PR c++/90750
	PR c++/79585
	* decl.c (grokdeclarator): Move dependent attribute to decl.
	* decl2.c (splice_template_attributes): No longer static.