* sv.po: Update.

	Revert:
	2020-04-30  Marek Polacek  <polacek@redhat.com>

	PR c++/94775
	* tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match.
	(check_aligned_type): Check if TYPE_USER_ALIGN match.

../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '1' (via 'I124MODE:n') or '4' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '1' (via 'I124MODE:n') or '' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '2' (via 'I124MODE:n') or '4' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '2' (via 'I124MODE:n') or '' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '4' (via 'I124MODE:n') or '' (via 'I48MODE:n')

The insn name already uses <I124MODE:n> explicitly, just the preparation
stmts don't, and as it creates a I124MODE lowpart subreg of a word mode
register, <I124MODE:n> seems obviously correct.

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

	* config/tilegx/tilegx.md
	(insn_stnt<I124MODE:n>_add<I48MODE:bitsuffix>): Use <I124MODE:n>
	rather than just <n>.

The libstdc++ manual documents that _T can not be used, because it's a
macro in system headers on some targets.

Backport from mainline
2020-05-01  Jonathan Wakely  <jwakely@redhat.com>

	PR libstdc++/94901
	* include/std/type_traits (__is_complete_or_unbounded): Replace
	BADNAME _T with _Tp.
	* testsuite/17_intro/badnames.cc: New test.

check_effective_target_fileio was added to
gcc/testsuite/lib/target-supports.exp the other day, without
documentation.

This patch adds the corresponding documentation.


for  gcc/ChangeLog

	* doc/sourcebuild.texi (Effective-Target Keywords): Document
	the newly-introduced fileio effective target.

cse_process_notes did a very simple substitution, which in the wrong
circumstances could create non-canonical RTL and invalid MEMs.
Various sticking plasters have been applied to cse_process_notes_1
to handle cases like ZERO_EXTEND, SIGN_EXTEND and UNSIGNED_FLOAT,
but I think this PR is a plaster too far.

The code is trying hard to avoid creating unnecessary rtl, which of
course is a good thing.  If we continue to do that, then we can end
up changing subexpressions while keeping the containing rtx.
This in turn means that validate_change will be a no-op on the
containing rtx, even if its contents have changed.  So in these
cases we have to apply validate_change to the individual subexpressions.

On the other hand, if we always apply validate_change to the
individual subexpressions, we'll end up calling validate_change
on something before it has been simplified and canonicalised.
And that's one of the situations we're trying to avoid.

There might be a middle ground in which we queue the validate_changes
as part of a group, and so can cancel the pending validate_changes
for subexpressions if there's a change in the outer expression.
But that seems even more ad-hoc than the current code.
It would also be quite an invasive change.

I think the best thing is just to hook into the existing
simplify_replace_fn_rtx function, keeping the REG and MEM handling
from cse_process_notes_1 essentially unchanged.  It can generate
more redundant rtl when a simplification takes place, but it has
the advantage of being relative well-used code (both directly
and via simplify_replace_rtx).

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

gcc/
	PR rtl-optimization/94740
	* cse.c (cse_process_notes_1): Replace with...
	(cse_process_note_1): ...this new function, acting as a
	simplify_replace_fn_rtx callback to process_note.  Handle only
	REGs and MEMs directly.  Validate the MEM if cse_process_note
	changes its address.
	(cse_process_notes): Replace with...
	(cse_process_note): ...this new function.
	(cse_extended_basic_block): Update accordingly, iterating over
	the register notes and passing individual notes to cse_process_note.

PR 94856 is a call graph verifier error.  We have a method which (in
the course of IPA-CP) loses its this pointer because it is unused and
the pass then does not clone all the this adjusting thunks and just
makes the calls go straight to the new clone - and then the verifier
complains that the edge does not seem to point to a clone of what it
used to.  This looked weird because the verifier actually has logic
detecting this case but it turns out that it is confused by inliner
body-saving mechanism which invents a new decl for the base function.

Making the inlining body-saving mechanism to correctly set
former_clone_of allows us to detect this case too.  Then we pass this
particular round of verification but the subsequent one fails because
we have inlined the function into its former thunk - which
subsequently does not have any callees, but the verifier still access
them and segfaults.  Therefore the patch also adds a test whether the
a former hunk even has any call.

2020-04-30  Martin Jambor  <mjambor@suse.cz>

	PR ipa/94856
	* cgraph.c (clone_of_p): Also consider thunks whih had their bodies
	saved by the inliner and thunks which had their call inlined.
	* ipa-inline-transform.c (save_inline_function_body): Fill in
	former_clone_of of new body holders.

	PR ipa/94856
	* g++.dg/ipa/pr94856.C: New test.

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

	* DEV-PHASE: Set to prerelease.

Template headers are not incrementally updated as we parse its parameters.
We maintain a dummy level until the closing > when we replace the dummy with
a real parameter set.  requires processing was expecting a properly populated
arg_vec in current_template_parms, and then creates a self-mapping of parameters
from that.  But we don't need to do that, just teach map_arguments to look at
TREE_VALUE when args is NULL.

	* constraint.cc (map_arguments): If ARGS is null, it's a
	self-mapping of parms.
	(finish_nested_requirement): Do not pass argified
	current_template_parms to normalization.
	(tsubst_nested_requirement): Don't assert no template parms.

This fixes a regression due to the conditional noexcept-specifier on
std::allocator::construct and std::allocator::destroy, as well as the
corresponding members of new_allocator, malloc_allocator, and
allocator_traits. Those noexcept-specifiers were using expressions which
might be ill-formed, which caused errors outside the immediate context
when checking for the presence of construct and destroy in SFINAE
contexts.

The fix is to use the is_nothrow_constructible and
is_nothrow_destructible type traits instead, because those traits are
safe to use even when the construction/destruction itself is not valid.

The is_nothrow_constructible trait will be false for a type that is not
also nothrow-destructible, even if the new-expression used in the
construct function body is actually noexcept. That's not the correct
answer, but isn't a problem because providing a noexcept-specifier on
these functions is not required by the standard anyway. If the answer is
false when it should be true, that's suboptimal but OK (unlike giving
errors for valid code, or giving a true answer when it should be false).

	PR libstdc++/89510
	* include/bits/alloc_traits.h (allocator_traits::_S_construct)
	(allocator_traits::_S_destroy)
	(allocator_traits<allocator<T>>::construct): Use traits in
	noexcept-specifiers.
	* include/bits/allocator.h (allocator<void>::construct)
	(allocator<void>::destroy): Likewise.
	* include/ext/malloc_allocator.h (malloc_allocator::construct)
	(malloc_allocator::destroy): Likewise.
	* include/ext/new_allocator.h (new_allocator::construct)
	(new_allocator::destroy): Likewise.
	* testsuite/20_util/allocator/89510.cc: New test.
	* testsuite/ext/malloc_allocator/89510.cc: New test.
	* testsuite/ext/new_allocator/89510.cc: New test.

The testcase ICEs because the range-based for generates three
artificial variables that need to be allocated to the coroutine
frame but, when walking the BIND_EXR that contains these, the
DECL_INITIAL for one of them refers to an entry appearing later,
which means that the frame entry hasn't been allocated when that
INITIAL is walked.

The solution is to defer walking the DECL_INITIAL/SIZE etc. until
all the BIND_EXPR vars have been processed.

gcc/cp/ChangeLog:

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

	PR c++/94886
	* coroutines.cc (transform_local_var_uses): Defer walking
	the DECL_INITIALs of BIND_EXPR vars until all the frame
	allocations have been made.

gcc/testsuite/ChangeLog:

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

	PR c++/94886
	* g++.dg/coroutines/pr94886-folly-3.C: New test.

The problem here is that target cleanup expressions have been
added to the initialisers for the awaitable (and returns of
non-trivial values from await_suspend() calls.  This is because
the expansion of the co_await into its control flow is not
apparent to the machinery adding the target cleanup expressions.
The solution being tested is simply to recreate target expressions
as the co_awaits are lowered.  Teaching the machinery to handle
walking co_await expressions in different ways at different points
(outside the coroutine transformation) seems overly complex.

gcc/cp/ChangeLog:

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

	PR c++/94883
	* coroutines.cc (register_awaits): Update target
	expressions for awaitable and suspend handle
	initializers.

gcc/testsuite/ChangeLog:

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

	PR c++/94883
	* g++.dg/coroutines/pr94883-folly-2.C: New test.

There are several places where the handling of a variable
declaration depends on whether it corresponds to a compiler
temporary, or to some other entity.  We were testing that var
decls were artificial in determining this.  However, proxy vars
are also artificial so that this is not sufficient.  The solution
is to exclude variables with a DECL_VALUE_EXPR as well, since
the value variable will not be a temporary.

gcc/cp/ChangeLog:

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

	PR c++/94879
	* coroutines.cc (build_co_await): Account for variables
	with DECL_VALUE_EXPRs.
	(captures_temporary): Likewise.
	(register_awaits): Likewise.

gcc/testsuite/ChangeLog:

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

	PR c++/94879
	* g++.dg/coroutines/pr94879-folly-1.C: New test.

gcc/ChangeLog:

	* pretty-print.c (pp_take_prefix): Fix spelling in comment.

Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by
build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1.

When we strip_typedefs the element of the array "const d", we see it's
a typedef_variant_p, so we look at its DECL_ORIGINAL_TYPE, which is
char, but we need to add the const qualifier, so we call
cp_build_qualified_type -> build_qualified_type
where get_qualified_type checks to see if we already have such a type
by walking the variants list, which in this case is:

  char -> c -> const char -> const char -> d -> const d

Because check_base_type only checks TYPE_ALIGN and not TYPE_USER_ALIGN,
we choose the first const char, which has TYPE_USER_ALIGN set.  If the
element type of an array has TYPE_USER_ALIGN, the array type gets it too.

So we can make check_base_type stricter.  I was afraid that it might make
us reuse types less often, but measuring showed that we build the same
amount of types with and without the patch, while bootstrapping.

	PR c++/94775
	* tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match.
	(check_aligned_type): Check if TYPE_USER_ALIGN match.

	* g++.dg/warn/Warray-bounds-10.C: New test.

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

	* config/aarch64/aarch64.h (TARGET_OUTLINE_ATOMICS): Define.
	* config/aarch64/aarch64.opt (moutline-atomics): Change to Int variable.
	* doc/invoke.texi (moutline-atomics): Document as on by default.

It was previously discussed that indirect branches cannot go to
NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html

Before the patch a bti j was inserted after the label in

  __attribute__((target("branch-protection=bti")))
  int foo (void)
  {
  label:
    return 0;
  }

This is not necessary and weakens the security protection.

gcc/ChangeLog:

	PR target/94748
	* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove
	the check for NOTE_INSN_DELETED_LABEL.

gcc/testsuite/ChangeLog:

	PR target/94748
	* gcc.target/aarch64/pr94748.c: New test.

From the generated manpages, it was not clear that its usage is
'-debuglib=<libname>'.

gcc/d/ChangeLog:

	* gdc.texi (Options for Linking): Clarify usage of -defaultlib= and
	-debuglib= options.

Corrects a previous change made to the SPARC stdc bindings, and
backports PPC-related fixes.  The library and language testsuite now
passes fully on powerpc64le-linux-gnu.

Fixes: PR d/90719
Fixes: PR d/94825

Reviewed-on: https://github.com/dlang/dmd/pull/11079
	     https://github.com/dlang/druntime/pull/3078
	     https://github.com/dlang/druntime/pull/3083

libphobos/ChangeLog:

	PR d/94825
	* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Remove
	config/powerpc/switchcontext.S
	* libdruntime/Makefile.in: Regenerate.
	* libdruntime/config/powerpc/callwithstack.S: Remove.
	* libdruntime/config/powerpc/switchcontext.S: Fix symbol name of
	fiber_switchContext.
	* libdruntime/core/thread.d: Disable fiber migration tests on PPC.
	* testsuite/libphobos.thread/fiber_guard_page.d: Set guardPageSize
	same as stackSize.

>   , CHANGES_URL ("gcc-10/changes.html#empty_base");
>
> where the macro would just use preprocessor string concatenation?

Ok, the following patch implements it (doesn't introduce a separate
macro and just uses CHANGES_ROOT_URL "gcc-10/changes.html#empty_base"),
in addition adds the documentation Joseph requested.

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

	* configure.ac (--with-documentation-root-url,
	--with-changes-root-url): Diagnose URL not ending with /,
	use AC_DEFINE_UNQUOTED instead of AC_SUBST.
	* opts.h (get_changes_url): Remove.
	* opts.c (get_changes_url): Remove.
	* Makefile.in (CFLAGS-opts.o): Don't add -DDOCUMENTATION_ROOT_URL
	or -DCHANGES_ROOT_URL.
	* doc/install.texi (--with-documentation-root-url,
	--with-changes-root-url): Document.
	* config/arm/arm.c (aapcs_vfp_is_call_or_return_candidate): Don't call
	get_changes_url and free, change url variable type to const char * and
	set it to CHANGES_ROOT_URL "gcc-10/changes.html#empty_base".
	* config/s390/s390.c (s390_function_arg_vector,
	s390_function_arg_float): Likewise.
	* config/aarch64/aarch64.c (aarch64_vfp_is_call_or_return_candidate):
	Likewise.
	* config/rs6000/rs6000-call.c (rs6000_discover_homogeneous_aggregate):
	Likewise.
	* config.in: Regenerate.
	* configure: Regenerate.

Remove two duplicate entries in isr_attribute_args ("abort" and
"ABORT").

2020-04-30  Christophe Lyon  <christophe.lyon@linaro.org>

	PR target/57002
	gcc/
	* config/arm/arm.c (isr_attribute_args): Remove duplicate entries.

This fixes a problem with the vec_store_len_r intrinsic.  The macros
mapping the intrinsic to a GCC builtin had the wrong signature.

With the patch an immediate length operand of vlrl/vstrl is handled
the same way as if it was passed in a register to vlrlr/vstrlr.
Values bigger than 15 always load the full vector.  If it can be
recognized that it is in effect a full vector register load or store
it is now implemented with vl/vst instead.

gcc/ChangeLog:

2020-04-30  Andreas Krebbel  <krebbel@linux.ibm.com>

	* config/s390/constraints.md ("j>f", "jb4"): New constraints.
	* config/s390/vecintrin.h (vec_load_len_r, vec_store_len_r): Fix
	macro definitions.
	* config/s390/vx-builtins.md ("vlrlrv16qi", "vstrlrv16qi"): Add a
	separate expander.
	("*vlrlrv16qi", "*vstrlrv16qi"): Add alternative for vl/vst.
	Change constraint for vlrl/vstrl to jb4.

gcc/testsuite/ChangeLog:

2020-04-30  Andreas Krebbel  <krebbel@linux.ibm.com>

	* gcc.target/s390/zvector/vec_load_len_r.c: New test.
	* gcc.target/s390/zvector/vec_store_len_r.c: New test.

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.