While bootstrapping GCC on S/390 the following warning/error is raised:

gcc/var-tracking.c:10239:34: error: 'pre' may be used uninitialized in this function [-Werror=maybe-uninitialized]
10239 |       VTI (bb)->out.stack_adjust += pre;
      |                                  ^

The lines of interest are:

  HOST_WIDE_INT pre, post = 0;
  // ...
  if (!frame_pointer_needed)
    {
      insn_stack_adjust_offset_pre_post (insn, &pre, &post);
      // ...
    }

  // ...
  adjust_insn (bb, insn);

  if (!frame_pointer_needed && pre)
    VTI (bb)->out.stack_adjust += pre;

Both if statements depend on global variable frame_pointer_needed.  In function
insn_stack_adjust_offset_pre_post local variable pre is initialized.  The
problematic part is the function call between both if statements.  Since
adjust_insn also calls functions which are defined in a different compilation
unit, we are not able to prove that global variable frame_pointer_needed is not
altered by adjust_insn and its siblings.  Thus we must assume that
frame_pointer_needed may be true before the call and false afterwards which
renders the warning true (admitted the location hint is not totally perfect).
By initialising pre we silence the warning.

gcc/ChangeLog:

2020-04-30  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

        * var-tracking.c (vt_initialize): Move variables pre and post
        into inner block and initialize both in order to fix warning
        about uninitialized use.  Remove unnecessary checks for
        frame_pointer_needed.

Ensure that CF does not equal NULL in function output_stack_usage_1
before calling fprintf.  This fixes the following warning/error:

gcc/toplev.c:976:13: error: argument 1 null where non-null expected [-Werror=nonnull]
  976 |     fprintf (cf, "\\n" HOST_WIDE_INT_PRINT_DEC " bytes (%s)",
      |     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  977 |       stack_usage,
      |       ~~~~~~~~~~~~
  978 |       stack_usage_kind_str[stack_usage_kind]);

An example call side where CF is NULL is in function output_stack_usage.

gcc/ChangeLog:

2020-04-30  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

	* toplev.c (output_stack_usage_1): Ensure that first
	argument to fprintf is not null.

The following patch attempts to use the diagnostics URL support if available
to provide more information about the C++17 empty base and C++20
[[no_unique_address]] empty class ABI changes in -Wpsabi diagnostics.

in GCC 10.1 at the end of the diagnostics is then in some terminals
underlined with a dotted line and points to a (to be written) anchor in
gcc-10/changes.html which we need to write anyway.

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

	* configure.ac (-with-changes-root-url): New configure option,
	defaulting to https://gcc.gnu.org/.
	* Makefile.in (CFLAGS-opts.o): Define CHANGES_ROOT_URL for
	opts.c.
	* pretty-print.c (get_end_url_string): New function.
	(pp_format): Handle %{ and %} for URLs.
	(pp_begin_url): Use pp_string instead of pp_printf.
	(pp_end_url): Use get_end_url_string.
	* opts.h (get_changes_url): Declare.
	* opts.c (get_changes_url): New function.
	* config/rs6000/rs6000-call.c: Include opts.h.
	(rs6000_discover_homogeneous_aggregate): Use %{in GCC 10.1%} instead
	of just in GCC 10.1 in diagnostics and add URL.
	* config/arm/arm.c (aapcs_vfp_is_call_or_return_candidate): Likewise.
	* config/aarch64/aarch64.c (aarch64_vfp_is_call_or_return_candidate):
	Likewise.
	* config/s390/s390.c (s390_function_arg_vector,
	s390_function_arg_float): Likewise.
	* configure: Regenerated.

	* c-format.c (PP_FORMAT_CHAR_TABLE): Add %{ and %}.

So, based on the yesterday's discussions, similarly to powerpc64le-linux
I've done some testing for s390x-linux too.

First of all, I found a bug in my patch from yesterday, it was printing
the wrong type like 'double' etc. rather than the class that contained such
the element.  Fix below.

For s390x-linux, I was using
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { double a; };
struct B : public X { double a; };
struct C : public Y { double a; };
struct D : public Z { double a; };
struct E : public U { double a; };
struct F { [[no_unique_address]] X x; double a; };
struct G { [[no_unique_address]] Y y; double a; };
struct H { [[no_unique_address]] Z z; double a; };
struct I { [[no_unique_address]] U u; double a; };
struct J { double a; [[no_unique_address]] X x; };
struct K { double a; [[no_unique_address]] Y y; };
struct L { double a; [[no_unique_address]] Z z; };
struct M { double a; [[no_unique_address]] U u; };
 #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)
as testcase and looking for "\tld\t%f0,".
While g++ 9 with -std=c++17 used to pass in fpr just
A, g++ 9 -std=c++14, as well as current trunk -std=c++14 & 17
and clang++ from today -std=c++14 & 17 all pass A, B, C
in fpr and nothing else.  The intent stated by Jason seems to be
that A, B, C, F, G, J, K should all be passed in fpr.

Attached are two (updated) versions of the patch on top of the
powerpc+middle-end patch just posted.

The first one emits two separate -Wpsabi warnings like powerpc, one for
the -std=c++14 vs. -std=c++17 ABI difference and one for GCC 9 vs. 10
[[no_unique_address]] passing changes, the other one is silent about the
second case.

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

	PR target/94704
	* config/s390/s390.c (s390_function_arg_vector,
	s390_function_arg_float): Use DECL_FIELD_ABI_IGNORED instead of
	cxx17_empty_base_field_p.  In -Wpsabi diagnostics use the type
	passed to the function rather than the type of the single element.
	Rename cxx17_empty_base_seen variable to empty_base_seen, change
	type to int, and adjust diagnostics depending on if the field
	has [[no_unique_attribute]] or not.

	* g++.target/s390/s390.exp: New file.
	* g++.target/s390/pr94704-1.C: New test.
	* g++.target/s390/pr94704-2.C: New test.
	* g++.target/s390/pr94704-3.C: New test.
	* g++.target/s390/pr94704-4.C: New test.

	PR libstdc++/94854
	* include/bits/basic_string.tcc: Update comment about explicit
	instantiations.

A few other macros seem to suffer from the same issue.  What I've done was:
cat gcc/config/i386/*intrin.h | sed -e ':x /\\$/ { N; s/\\\n//g ; bx }' \
| grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]].*(' | sed 's/[ 	]\+/ /g' \
> /tmp/macros
and then looking for regexps:
)[a-zA-Z]
) [a-zA-Z]
[a-zA-Z][-+*/%]
[a-zA-Z] [-+*/%]
[-+*/%][a-zA-Z]
[-+*/%] [a-zA-Z]
in the resulting file.

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

	PR target/94832
	* config/i386/avx512bwintrin.h (_mm512_alignr_epi8,
	_mm512_mask_alignr_epi8, _mm512_maskz_alignr_epi8): Wrap macro operands
	used in casts into parens.
	* config/i386/avx512fintrin.h (_mm512_cvt_roundps_ph, _mm512_cvtps_ph,
	_mm512_mask_cvt_roundps_ph, _mm512_mask_cvtps_ph,
	_mm512_maskz_cvt_roundps_ph, _mm512_maskz_cvtps_ph,
	_mm512_mask_cmp_epi64_mask, _mm512_mask_cmp_epi32_mask,
	_mm512_mask_cmp_epu64_mask, _mm512_mask_cmp_epu32_mask,
	_mm512_mask_cmp_round_pd_mask, _mm512_mask_cmp_round_ps_mask,
	_mm512_mask_cmp_pd_mask, _mm512_mask_cmp_ps_mask): Likewise.
	* config/i386/avx512vlbwintrin.h (_mm256_mask_alignr_epi8,
	_mm256_maskz_alignr_epi8, _mm_mask_alignr_epi8, _mm_maskz_alignr_epi8,
	_mm256_mask_cmp_epu8_mask): Likewise.
	* config/i386/avx512vlintrin.h (_mm_mask_cvtps_ph, _mm_maskz_cvtps_ph,
	_mm256_mask_cvtps_ph, _mm256_maskz_cvtps_ph): Likewise.
	* config/i386/f16cintrin.h (_mm_cvtps_ph, _mm256_cvtps_ph): Likewise.
	* config/i386/shaintrin.h (_mm_sha1rnds4_epu32): Likewise.

As reported in the PR, while most intrinsic -O0 macro argument uses
are properly wrapped in ()s or used in context where having a complex
expression passed as the argument doesn't pose a problem (e.g. when
macro argument use is in between commas, or between ( and comma, or
between comma and ) etc.), especially the gather/scatter macros don't do
this and if one passes to some macro e.g. x + y as argument, the
corresponding inline function would do cast on the argument, but
the macro does (int) ARG, then it is (int) x + y rather than (int) (x + y).

The following patch fixes those issues in *gather/*scatter*; additionally,
the AVX2 macros were passing incorrect mask of e.g.
(__v2df)_mm_set1_pd((double)(long long int) -1)
which is IMHO equivalent to
(__v2df){-1.0, -1.0}
when it really wants to pass __v2df vector with all bits set.
I've used what the inline functions use for those cases.

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

	PR target/94832
	* config/i386/avx2intrin.h (_mm_mask_i32gather_pd,
	_mm256_mask_i32gather_pd, _mm_mask_i64gather_pd,
	_mm256_mask_i64gather_pd, _mm_mask_i32gather_ps,
	_mm256_mask_i32gather_ps, _mm_mask_i64gather_ps,
	_mm256_mask_i64gather_ps, _mm_i32gather_epi64,
	_mm_mask_i32gather_epi64, _mm256_i32gather_epi64,
	_mm256_mask_i32gather_epi64, _mm_i64gather_epi64,
	_mm_mask_i64gather_epi64, _mm256_i64gather_epi64,
	_mm256_mask_i64gather_epi64, _mm_i32gather_epi32,
	_mm_mask_i32gather_epi32, _mm256_i32gather_epi32,
	_mm256_mask_i32gather_epi32, _mm_i64gather_epi32,
	_mm_mask_i64gather_epi32, _mm256_i64gather_epi32,
	_mm256_mask_i64gather_epi32): Surround macro parameter uses with
	parens.
	(_mm_i32gather_pd, _mm256_i32gather_pd, _mm_i64gather_pd,
	_mm256_i64gather_pd, _mm_i32gather_ps, _mm256_i32gather_ps,
	_mm_i64gather_ps, _mm256_i64gather_ps): Likewise.  Don't use
	as mask vector containing -1.0 or -1.0f elts, but instead vector
	with all bits set using _mm*_cmpeq_p? with zero operands.
	* config/i386/avx512fintrin.h (_mm512_i32gather_ps,
	_mm512_mask_i32gather_ps, _mm512_i32gather_pd,
	_mm512_mask_i32gather_pd, _mm512_i64gather_ps,
	_mm512_mask_i64gather_ps, _mm512_i64gather_pd,
	_mm512_mask_i64gather_pd, _mm512_i32gather_epi32,
	_mm512_mask_i32gather_epi32, _mm512_i32gather_epi64,
	_mm512_mask_i32gather_epi64, _mm512_i64gather_epi32,
	_mm512_mask_i64gather_epi32, _mm512_i64gather_epi64,
	_mm512_mask_i64gather_epi64, _mm512_i32scatter_ps,
	_mm512_mask_i32scatter_ps, _mm512_i32scatter_pd,
	_mm512_mask_i32scatter_pd, _mm512_i64scatter_ps,
	_mm512_mask_i64scatter_ps, _mm512_i64scatter_pd,
	_mm512_mask_i64scatter_pd, _mm512_i32scatter_epi32,
	_mm512_mask_i32scatter_epi32, _mm512_i32scatter_epi64,
	_mm512_mask_i32scatter_epi64, _mm512_i64scatter_epi32,
	_mm512_mask_i64scatter_epi32, _mm512_i64scatter_epi64,
	_mm512_mask_i64scatter_epi64): Surround macro parameter uses with
	parens.
	* config/i386/avx512pfintrin.h (_mm512_prefetch_i32gather_pd,
	_mm512_prefetch_i32gather_ps, _mm512_mask_prefetch_i32gather_pd,
	_mm512_mask_prefetch_i32gather_ps, _mm512_prefetch_i64gather_pd,
	_mm512_prefetch_i64gather_ps, _mm512_mask_prefetch_i64gather_pd,
	_mm512_mask_prefetch_i64gather_ps, _mm512_prefetch_i32scatter_pd,
	_mm512_prefetch_i32scatter_ps, _mm512_mask_prefetch_i32scatter_pd,
	_mm512_mask_prefetch_i32scatter_ps, _mm512_prefetch_i64scatter_pd,
	_mm512_prefetch_i64scatter_ps, _mm512_mask_prefetch_i64scatter_pd,
	_mm512_mask_prefetch_i64scatter_ps): Likewise.
	* config/i386/avx512vlintrin.h (_mm256_mmask_i32gather_ps,
	_mm_mmask_i32gather_ps, _mm256_mmask_i32gather_pd,
	_mm_mmask_i32gather_pd, _mm256_mmask_i64gather_ps,
	_mm_mmask_i64gather_ps, _mm256_mmask_i64gather_pd,
	_mm_mmask_i64gather_pd, _mm256_mmask_i32gather_epi32,
	_mm_mmask_i32gather_epi32, _mm256_mmask_i32gather_epi64,
	_mm_mmask_i32gather_epi64, _mm256_mmask_i64gather_epi32,
	_mm_mmask_i64gather_epi32, _mm256_mmask_i64gather_epi64,
	_mm_mmask_i64gather_epi64, _mm256_i32scatter_ps,
	_mm256_mask_i32scatter_ps, _mm_i32scatter_ps, _mm_mask_i32scatter_ps,
	_mm256_i32scatter_pd, _mm256_mask_i32scatter_pd, _mm_i32scatter_pd,
	_mm_mask_i32scatter_pd, _mm256_i64scatter_ps,
	_mm256_mask_i64scatter_ps, _mm_i64scatter_ps, _mm_mask_i64scatter_ps,
	_mm256_i64scatter_pd, _mm256_mask_i64scatter_pd, _mm_i64scatter_pd,
	_mm_mask_i64scatter_pd, _mm256_i32scatter_epi32,
	_mm256_mask_i32scatter_epi32, _mm_i32scatter_epi32,
	_mm_mask_i32scatter_epi32, _mm256_i32scatter_epi64,
	_mm256_mask_i32scatter_epi64, _mm_i32scatter_epi64,
	_mm_mask_i32scatter_epi64, _mm256_i64scatter_epi32,
	_mm256_mask_i64scatter_epi32, _mm_i64scatter_epi32,
	_mm_mask_i64scatter_epi32, _mm256_i64scatter_epi64,
	_mm256_mask_i64scatter_epi64, _mm_i64scatter_epi64,
	_mm_mask_i64scatter_epi64): Likewise.

While bootstrapping GCC on S/390 the following warning occurs:

gcc/fortran/io.c: In function 'bool gfc_resolve_dt(gfc_code*, gfc_dt*, locus*)':
gcc/fortran/io.c:3857:7: error: 'num' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 3857 |       if (num == 0)
      |       ^~
gcc/fortran/io.c:3843:11: note: 'num' was declared here
 3843 |       int num;

Since gfc_resolve_dt is a non-static function we cannot assume anything about
argument DT.  Argument DT gets passed to function check_io_constraints which
passes values depending on DT, namely dt->asynchronous->value.character.string
to function compare_to_allowed_values as well as argument warn which is true as
soon as DT->dterr is true.  Thus both arguments depend on DT.

If function compare_to_allowed_values is called with
dt->asynchronous->value.character.string not being an allowed value, and
ALLOWED_F2003 as well as ALLOWED_GNU being NULL (which is the case at the
particular call side), and WARN equals true, then the function returns with a
non-zero value and leaves num uninitialized which renders the warning true.

Initialized num to -1 and added an assert statement.

gcc/fortran/ChangeLog:

2020-04-29  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

        PR fortran/94769
        * io.c (check_io_constraints): Initialize local variable num to
        -1 and assert that it receives a meaningful value by function
        compare_to_allowed_values.

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

	* config/h8300/h8300.md (H8/SX div patterns): All H8/SX specific
	division instructions are 4 bytes long.

This is the rs6000 version of the earlier committed x86, aarch64 and arm
fixes, as create_tmp_var_raw is used because the C FE can call this outside
of function context, we need to make sure the first references to those
VAR_DECLs are through a TARGET_EXPR, so that it gets gimple_add_tmp_var
marked in whatever function it gets expanded in.  Without that DECL_CONTEXT
is NULL and the vars aren't added as local decls of the containing function.

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

	PR target/94826
	* config/rs6000/rs6000.c (rs6000_atomic_assign_expand_fenv): Use
	TARGET_EXPR instead of MODIFY_EXPR for first assignment to
	fenv_var, fenv_clear and old_fenv variables.  For fenv_addr
	take address of TARGET_EXPR of fenv_var with void_node initializer.
	Formatting fixes.

Array retval is not necessarily initialized by function is_call_safe and
may be used afterwards.  Thus, initialize it explicitly.

gcc/ChangeLog:

2020-04-29  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

	PR tree-optimization/94774
	* gimple-ssa-sprintf.c (try_substitute_return_value): Initialize
	variable retval.

This patch makes the order in which template parameters appear in the
TREE_LIST returned by find_template_parameters deterministic between
runs.

The current nondeterminism is semantically harmless, but it has the
undesirable effect of causing some concepts diagnostics which print a
constraint's parameter mapping via pp_cxx_parameter_mapping to also be
nondeterministic, as in the testcases below.

gcc/cp/ChangeLog:

	PR c++/94830
	* pt.c (find_template_parameter_info::parm_list): New field.
	(keep_template_parm): Use the new field to build up the
	parameter list here instead of ...
	(find_template_parameters): ... here.  Return ftpi.parm_list.

gcc/testsuite/ChangeLog:

	PR c++/94830
	* g++.dg/concepts/diagnostics12.C: Clarify the dg-message now
	that the corresponding diagnostic is deterministic.
	* g++.dg/concepts/diagnostics13.C: New test.

This predicate is now used by aarch64 targets.

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

gcc/
	* calls.h (cxx17_empty_base_field_p): Turn into a function declaration.
	* calls.c (cxx17_empty_base_field_p): New function.  Check
	DECL_ARTIFICIAL and RECORD_OR_UNION_TYPE_P in addition to the
	previous checks.

Allow -fcf-protection with external thunk since the external thunk can be
made compatible with -fcf-protection.

gcc/

	PR target/93654
	* config/i386/i386-options.c (ix86_set_indirect_branch_type):
	Allow -fcf-protection with -mindirect-branch=thunk-extern and
	-mfunction-return=thunk-extern.
	* doc/invoke.texi: Update notes for -fcf-protection=branch with
	-mindirect-branch=thunk-extern and -mindirect-return=thunk-extern.

gcc/testsuite/

	PR target/93654
	* gcc.target/i386/pr93654.c: New test.

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

gcc/
	* doc/sourcebuild.texi: Add missing arm_arch_v8a_hard_ok anchor.

Essentially the same fix as for x86.

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

gcc/
	* config/arm/arm-builtins.c (arm_atomic_assign_expand_fenv): Use
	TARGET_EXPR instead of MODIFY_EXPR for the first assignments to
	fenv_var and new_fenv_var.

This patch makes the ABI code ignore zero-sized [[no_unique_address]]
fields when deciding whether something is a HFA or HVA.

For the tests, I wanted an -march setting that was stable enough
to use check-function-bodies and also wanted to force -mfloat-abi=hard.
I couldn't see any existing way of doing both together, since most
arm-related effective-target keywords are agnostic about the choice
between -mfloat-abi=softfp and -mfloat-abi=hard.  I therefore added
a new effective-target keyword for this combination.

I used the arm_arch_* framework for the effective-target rather than
writing a new set of custom Tcl routines.  This has the nice property
of separating the "compile and assemble" cases from the "link and run"
cases.  I only need compilation to work for the new tests, so requiring
linking to work would be an unnecessary restriction.

However, including an ABI requirement is arguably stretching what the
list was originally intended to handle.  The name arm_arch_v8a_hard
doesn't fit very naturally with some of the NEON-based tests.
On the other hand, the naming convention isn't entirely consistent,
so any choice would be inconsistent with something.

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

gcc/
	* doc/sourcebuild.texi (arm_arch_v8a_hard_ok): Document new
	effective-target keyword.
	(arm_arch_v8a_hard_multilib): Likewise.
	(arm_arch_v8a_hard): Document new dg-add-options keyword.
	* config/arm/arm.c (arm_return_in_memory): Note that the APCS
	code is deprecated and has not been updated to handle
	DECL_FIELD_ABI_IGNORED.
	(WARN_PSABI_EMPTY_CXX17_BASE): New constant.
	(WARN_PSABI_NO_UNIQUE_ADDRESS): Likewise.
	(aapcs_vfp_sub_candidate): Replace the boolean pointer parameter
	avoid_cxx17_empty_base with a pointer to a bitmask.  Ignore fields
	whose DECL_FIELD_ABI_IGNORED bit is set when determining whether
	something actually is a HFA or HVA.  Record whether we see a
	[[no_unique_address]] field that previous GCCs would not have
	ignored in this way.
	(aapcs_vfp_is_call_or_return_candidate): Update the calls to
	aapcs_vfp_sub_candidate and report a -Wpsabi warning for the
	[[no_unique_address]] case.  Use TYPE_MAIN_VARIANT in the
	diagnostic messages.
	(arm_needs_doubleword_align): Add a comment explaining why we
	consider even zero-sized fields.

gcc/testsuite/
	* lib/target-supports.exp: Add v8a_hard to the list of arm_arch_*
	targets.
	* g++.target/arm/no_unique_address_1.C: New test.
	* g++.target/arm/no_unique_address_2.C: Likewise.

This ICE appears because gcc will stream it to the function_body section
when processing the variable with the initial value of the constructor
type, and the error_mark_node to the decls section.
When recompiling, the value obtained with DECL_INITIAL will be error_mark.

2020-04-29  Richard Biener  <rguenther@suse.de>
	    Li Zekun  <lizekun1@huawei.com>

	PR lto/94822
	* tree.c (component_ref_size): Guard against error_mark_node
	DECL_INITIAL as it happens with LTO.

	* gcc.dg/lto/pr94822_0.c: New testcase.
	* gcc.dg/lto/pr94822_1.c: Alternate file.
	* gcc.dg/lto/pr94822.h: Likewise.

This patch makes the ABI code ignore zero-sized [[no_unique_address]]
fields when deciding whether something is a HFA or HVA.

As things stood, we'd get two sets of -Wpsabi warnings, one when
trying to decide whether something was an SVE function, and another
when actually processing the function definition or function call.
The patch therefore makes aapcs_vfp_sub_candidate honour the
CUMULATIVE_ARGS "silent_p" flag where applicable.

This doesn't stop all duplicate warnings for parameters, and I suspect
we'll get duplicate warnings for return values too, but it should be
better than nothing.

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

gcc/
	* config/aarch64/aarch64.c (aarch64_function_arg_alignment): Add a
	comment explaining why we consider even zero-sized fields.
	(WARN_PSABI_EMPTY_CXX17_BASE): New constant.
	(WARN_PSABI_NO_UNIQUE_ADDRESS): Likewise.
	(aapcs_vfp_sub_candidate): Replace the boolean pointer parameter
	avoid_cxx17_empty_base with a pointer to a bitmask.  Ignore fields
	whose DECL_FIELD_ABI_IGNORED bit is set when determining whether
	something actually is a HFA or HVA.  Record whether we see a
	[[no_unique_address]] field that previous GCCs would not have
	ignored in this way.
	(aarch64_vfp_is_call_or_return_candidate): Add a parameter to say
	whether diagnostics should be suppressed.  Update the calls to
	aapcs_vfp_sub_candidate and report a -Wpsabi warning for the
	[[no_unique_address]] case.
	(aarch64_return_in_msb): Update call accordingly, never silencing
	diagnostics.
	(aarch64_function_value): Likewise.
	(aarch64_return_in_memory_1): Likewise.
	(aarch64_init_cumulative_args): Likewise.
	(aarch64_gimplify_va_arg_expr): Likewise.
	(aarch64_pass_by_reference_1): Take a CUMULATIVE_ARGS pointer and
	use it to decide whether arch64_vfp_is_call_or_return_candidate
	should be silent.
	(aarch64_pass_by_reference): Update calls accordingly.
	(aarch64_vfp_is_call_candidate): Use the CUMULATIVE_ARGS argument
	to decide whether arch64_vfp_is_call_or_return_candidate should be
	silent.

gcc/testsuite/
	* g++.target/aarch64/no_unique_address_1.C: New test.
	* g++.target/aarch64/no_unique_address_2.C: Likewise.

mve.exp changed the default dg-do action to "assemble", but then
left it like that for later exp files.  This meant that in a
two-multilib test run, the first arm.exp run would have a default
of "dg-do compile" and the second would have a default of
"dg-do assemble".

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

gcc/testsuite/
	* g++.target/arm/mve.exp: Restore the original dg-do-what-default
	before finishing.

A typo in the macro call meant that the #error always triggered.

libphobos/ChangeLog:

	* testsuite/lib/libphobos.exp (check_effective_target_linux_pre_2639):
	Fix KERNEL_VERSION condition.

Adds classKind information to the front-end AST, which in turn allows us
to fix code generation of type names for extern(C) and extern(C++)
structs and classes.  Inspecting such types inside a debugger now just
works without the need to 'cast(module_name.cxx_type)'.

gcc/d/ChangeLog:

	* d-codegen.cc (d_decl_context): Don't include module in the name of
	class and struct types that aren't extern(D).

This is a simple fix for pr94820.
The PR was only fixed on i386, the same error was also reported on aarch64.
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-29  Haijian Zhang  <z.zhanghaijian@huawei.com>

	PR target/94820
	* config/aarch64/aarch64-builtins.c
	(aarch64_atomic_assign_expand_fenv): Use TARGET_EXPR instead of
	MODIFY_EXPR for first assignment to fenv_cr, fenv_sr and
	new_fenv_var.

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.