Fix a problem with commit c8e759b4 ("libgomp/test: Fix compilation
for build sysroot") that caused a regression in some standalone test
environments where testsuite/libgomp-test-support.exp is used, but the
compiler is expected to be determined by `[find_gcc]', and set the
GCC_UNDER_TEST TCL variable in testsuite/libgomp-site-extra.exp instead.

	libgomp/
	* configure.ac: Add testsuite/libgomp-site-extra.exp to output
	files.
	* configure: Regenerate.
	* testsuite/libgomp-site-extra.exp.in: New file.
	* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Remove
	variable.
	* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
	variable.
	* testsuite/Makefile.in: Regenerate.

Fix a problem with the libatomic testsuite using a method to determine
the compiler to use resulting in the tool being different from one the
library has been built with, and causing a catastrophic failure from the
lack of a suitable `--sysroot=' option where the `--with-build-sysroot='
configuration option has been used to build the compiler resulting in
the inability to link executables.

Address this problem by providing a DejaGNU configuration file defining
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC
by autoconf, which will have all the required options set for the target
compiler to build executables in the environment configured, removing
failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors)
Excess errors:
.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm

UNRESOLVED: libatomic.c/atomic-compare-exchange-1.c compilation failed to produce executable

and bringing overall test results for the `riscv64-linux-gnu' target
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user
emulation mode as the target board) from:

		=== libatomic Summary ===

# of unexpected failures	27
# of unresolved testcases	27

to:

		=== libatomic Summary ===

# of expected passes		54

	libatomic/
	* configure.ac: Add testsuite/libatomic-site-extra.exp to output
	files.
	* configure: Regenerate.
	* libatomic/testsuite/libatomic-site-extra.exp.in: New file.
	* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
	variable.
	* testsuite/Makefile.in: Regenerate.

getopt.c hangs the compiler on h8300-elf with -O2 -g, because the
IL contains addition of constant 0, the first PLUS operand is determined
to have the SP_DERIVED_VALUE_P and the new code in cselib recurses
indefinitely on seeing SP_DERIVED_VALUE_P with locs of
(plus:P SP_DERIVED_VALUE_P (const_int 0)).

Fixed by making sure cselib_subst_to_values canonicalizes it, hashing
already hashes it the same too.

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

	* cselib.c (cselib_subst_to_values): For SP_DERIVED_VALUE_P
	+ const0_rtx return the SP_DERIVED_VALUE_P.

	* sv.po: Update.

	* eo.po: Update.

gcc/fortran/ChangeLog:

2020-04-06  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/93686
	* decl.c (gfc_match_data): Handle data matching for derived type
	pointers.

gcc/testsuite/ChangeLog:

2020-04-06  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/93686
	* gfortran.dg/pr93686_1.f90: New test.
	* gfortran.dg/pr93686_2.f90: Likewise.
	* gfortran.dg/pr93686_3.f90: Likewise.
	* gfortran.dg/pr93686_4.f90: Likewise.

This test verifies, by using a weak reference to _Unwind_RaiseException,
that performing division by zero does not cause that symbol to get
indirectly pulled into our closure.

The testing methodology unfortunately does not work on VxWorks targets
when building in kernel mode. This is inherent to how kernel mode
on VxWorks works: The link is only partial and the remaining symbols
which have not been resolved already get automatically resolved by
the VxWorks loader at the moment the module is loaded onto the target,
prior to execution. The resolution includes weak symbols too, which
defeats the purpose of this test.

gcc/testsuite/

        * gcc.target/arm/div64-unwinding.c: Skip on vxworks_kernel targets.

lra_assign has an assert to make sure that no pseudo is allocated
to a conflicting hard register.  It used to be restricted to
!flag_ipa_ra, but in g:a1e6ee38 I'd enabled it for
flag_ipa_ra too.  It then tripped a few times while building
libstdc++ for mips-mti-linux.

Previous patches fixed one of the problems: registers clobbered
by the taking of an exception were being treated as live at the
beginning of the EH receiver, and this got propagated to predecessor
blocks.  But it turns out that there was a second problem: eh_return
data registers were also being marked live in the same way.

These registers are defined by the unwinder and so in reality they
are live on entry to the EH receiver.  But definitions can only happen
in blocks, not on edges, so for liveness purposes we use artificial
definitions at the start of the EH receiver.  process_bb_lives should
therefore model the effect of a definition, not a plain use.

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

gcc/
	PR rtl-optimization/92989
	* lra-lives.c (process_bb_lives): Do not treat eh_return data
	registers as being live at the beginning of the EH receiver.

	PR libstdc++/94498
	* include/bits/char_traits.h (__gnu_cxx::char_traits::move): Make it
	usable in constant expressions for C++20.
	(__gnu_cxx::char_traits::copy, __gnu_cxx::char_traits::assign): Add
	_GLIBCXX20_CONSTEXPR.
	(std::char_traits<char>, std::char_traits<wchar_t>)
	(std::char_traits<char8_t>): Make move, copy and assign usable in
	constant expressions for C++20.
	(std::char_traits<char16_t>, std::char_traits<char32_t>): Make move
	and copy usable in constant expressions for C++20.
	* include/std/string_view (basic_string_view::copy): Add
	_GLIBCXX20_CONSTEXPR.
	* testsuite/21_strings/basic_string_view/operations/copy/char/
	constexpr.cc: New test.
	* testsuite/21_strings/basic_string_view/operations/copy/wchar_t/
	constexpr.cc: New test.

Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:

      /* ??? Here's to hoping the front end fills in all of the indices,
         so we don't have to figure out what's missing ourselves.  */
      gcc_assert (purpose);

The indexes weren't filled because we never called reshape_init: for
a constructor that represents parenthesized initialization of an
aggregate we don't allow brace elision or designated initializers.

	PR c++/94155 - crash in gimplifier with paren init of aggregates.
	* init.c (build_vec_init): Fill in indexes.

	* g++.dg/cpp2a/paren-init22.C: New test.

	* doc/xml/manual/appendix_contributing.xml: Refer to Git
	documentation instead of Subversion.  Switch to https.
	* doc/html/manual/appendix_contributing.html: Regenerate.

Try to keep tests order by distinct number (and with a short
descriptive name appended).

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

	* g++.dg/coroutines/torture/co-await-14-template-traits.C: Rename...
	* g++.dg/coroutines/torture/co-await-16-template-traits.C: to this.
	* g++.dg/coroutines/torture/co-await-15-capture-comp-ref.C: Rename..
	* g++.dg/coroutines/torture/co-await-17-capture-comp-ref.C: to this.

	* extend.texi: Add free to list of ISO C90 functions that
	are recognized by the compiler.

Microblaze: Fixed missing save of r18 in fast_interrupt. Register 18 is used as a clobber register, and must be stored when entering a fast_interrupt. Before this fix, register 18 was only saved if it was used directly in the interrupt function.

    However, if the fast_interrupt function called a function that used
    r18, the register would not be saved, and thus be mangled
    upon returning from the interrupt.

	* config/microblaze/microblaze.c (microblaze_must_save_register): Check
	for fast_interrupt.

Microblaze: Modified trap instruction There is a bug in trap instruction generation. Instead of "bri 0" instruction "brki r0, -1" was used, corrected it now.

        * gcc/config/microblaze/microblaze.md (trap): Update output pattern.

        * gcc.target/microblaze/others/builtin-trap.c: Update expected output.

On the following testcase, in gdb ptype S<long>::m1 prints long as return
type, but all the other methods show void instead.
PR53756 added code to add_type_attribute if the return type is
auto/decltype(auto), but we actually should look through references,
pointers and qualifiers.
Haven't included there DW_TAG_atomic_type, because I think at least ATM
one can't use that in C++.  Not sure about DW_TAG_array_type or what else
could be deduced.

> http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a
> decl-specifier.
>
> http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template
> argument can be deduced.
>
> Looks like you are missing arrays, pointers to members, and function return
> types.

2020-04-04  Hannes Domani  <ssbssa@yahoo.de>
	    Jakub Jelinek  <jakub@redhat.com>

	PR debug/94459
	* dwarf2out.c (gen_subprogram_die): Look through references, pointers,
	arrays, pointer-to-members, function types and qualifiers when
	checking if in-class DIE had an 'auto' or 'decltype(auto)' return type
	to emit type again on definition.

	* g++.dg/debug/pr94459.C: New test.

Co-Authored-By: Hannes Domani <ssbssa@yahoo.de>

	* generic-morestack.c: Only use __mmap on glibc >= 2.26.

We skip over other conversion codes when mangling expressions, we should do
the same with IMPLICIT_CONV_EXPR.

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

	PR c++/91377
	* mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR.

This removes the use of replace_placeholders in cxx_eval_constant_expression
(which is causing the new test lambda-this6.C to ICE due to replace_placeholders
mutating the shared TARGET_EXPR_INITIAL tree which then trips up the
gimplifier).

In its place, this patch adds a 'parent' field to constexpr_ctx which is used to
store a pointer to an outer constexpr_ctx that refers to another object under
construction.  With this new field, we can beef up lookup_placeholder to resolve
PLACEHOLDER_EXPRs which refer to former objects under construction, which fixes
PR94205 without needing to do replace_placeholders.  Also we can now respect the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag when resolving PLACEHOLDER_EXPRs, and
doing so fixes the constexpr analogue of PR79937.

gcc/cp/ChangeLog:

	PR c++/94205
	PR c++/79937
	* constexpr.c (struct constexpr_ctx): New field 'parent'.
	(cxx_eval_bare_aggregate): Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY
	flag from the original constructor to the reduced constructor.
	(lookup_placeholder): Prefer to return the outermost matching object
	by recursively calling lookup_placeholder on the 'parent' context,
	but don't cross CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.
	(cxx_eval_constant_expression): Link the 'ctx' context to the 'new_ctx'
	context via 'new_ctx.parent' when being expanded without an explicit
	target.  Don't call replace_placeholders.
	(cxx_eval_outermost_constant_expr): Initialize 'ctx.parent' to NULL.

gcc/testsuite/ChangeLog:

	PR c++/94205
	PR c++/79937
	* g++.dg/cpp1y/pr79937-5.C: New test.
	* g++.dg/cpp1z/lambda-this6.C: New test.

This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR.  Evaluation of the initializer could add new elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any pointers to
or assumptions about the CONSTRUCTOR's elements, and so these routines should be
prepared for that.

To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the constructor_elt pointers through which
we're assigning, after it evaluates the initializer.  Care is taken to to not
slow down the common case where the initializer does not modify the underlying
CONSTRUCTOR.

gcc/cp/ChangeLog:

	PR c++/94219
	PR c++/94205
	* constexpr.c (get_or_insert_ctor_field): Split out (while adding
	support for VECTOR_TYPEs, and optimizations for the common case)
	from ...
	(cxx_eval_store_expression): ... here.  Rename local variable
	'changed_active_union_member_p' to 'activated_union_member_p'.  Record
	the sequence of indexes into 'indexes' that yields the subobject we're
	assigning to.  Record the integer offsets of the constructor indexes
	we're assigning through into 'index_pos_hints'.  After evaluating the
	initializer of the store expression, recompute 'valp' using 'indexes'
	and using 'index_pos_hints' as hints.
	(cxx_eval_bare_aggregate): Tweak comments.  Use get_or_insert_ctor_field
	to recompute the constructor_elt pointer we're assigning through after
	evaluating each initializer.

gcc/testsuite/ChangeLog:

	PR c++/94219
	PR c++/94205
	* g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
	* g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
	* g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
	* g++.dg/cpp1z/lambda-this5.C: New test.

gcc/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	PR ipa/93940
	* ipa-fnsummary.c (vrp_will_run_p): New function.
	(fre_will_run_p): New function.
	(evaluate_properties_for_edge): Use it.
	* ipa-inline.c (can_inline_edge_by_limits_p): Do not inline
	!optimize_debug to optimize_debug.

gcc/testsuite/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	* g++.dg/tree-ssa/pr93940.C: New test.

A recent change to cmcstl2 led to two tests failing due to this bug: our
valid expression checking in the context of a requires-expression wasn't
catching that an expression of member function type can only appear as the
function operand of a call expression.  Fixed by using convert_to_void to do
the same checking as a discarded-value expression.

This patch also fixes 67825, which already had a testcase, but the testcase
was testing for the wrong behavior.

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

	PR c++/67825
	* constraint.cc (tsubst_valid_expression_requirement): Call
	convert_to_void.

The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached from
the other lambda-expression.  This patch fixes this in two ways:

1) Avoid reusing a TARGET_EXPR from another function.
2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become
<TARGET_EXPR<NON_LVALUE_EXPR<TARGET_EXPR ...>>>, which doesn't make any
sense.

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

	PR c++/94453
	* constexpr.c (maybe_constant_value): Use break_out_target_exprs.
	* expr.c (mark_use) [VIEW_CONVERT_EXPR]: Don't wrap a TARGET_EXPR in
	NON_LVALUE_EXPR.

this patch fixes wrong code on a testcase where inline predicts
builtin_constant_p to be true but we fail to optimize its parameter to constant
becuase FRE is not run and the value is passed by an aggregate.

This patch makes the inline predicates to disable aggregate tracking
when FRE is not going to be run and similarly value range when VRP is not
going to be run.

This is just partial fix.  Even with it we can arrange FRE/VRP to fail and
produce wrong code, unforutnately.

I think for GCC11 I will need to implement transformation in ipa-inline
but this is bit hard to do: predicates only tracks that value will be constant
and do not track what constant to be.

Optimizing builtin_constant_p in a conditional is not going to do good job
when the value is used later in a place that expects it to be constant.
This is pre-existing problem that is not limited to inline tracking. For example,
FRE may do the transofrm at one place but not in another due to alias oracle
walking limits.

So I am not sure what full fix would be :(

gcc/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	PR ipa/93940
	* ipa-fnsummary.c (vrp_will_run_p): New function.
	(fre_will_run_p): New function.
	(evaluate_properties_for_edge): Use it.
	* ipa-inline.c (can_inline_edge_by_limits_p): Do not inline
	!optimize_debug to optimize_debug.

gcc/testsuite/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	* g++.dg/tree-ssa/pr93940.C: New test.

The following testcase ICEs, because at one point we see the
SP_DERIVED_VALUE_P VALUE as useless (not PRESERVED_VALUE_P and no locs)
and so expect it to be discarded as useless.  But, later on we
are adding some new VALUE that is equivalent to it, and when adding
the equivalency that that new VALUE is equal to this SP_DERIVED_VALUE_P,
new_elt_loc_list has code for VALUE canonicalization and reverses addition
if uid is smaller, and at that point a new loc is added to the
SP_DERIVED_VALUE_P VALUE and it isn't discarded as useless anymore.
Now, I think we don't want to discard the SP_DERIVED_VALUE_P values
even if they have no locs, because they still have the special behaviour
that they then force other new VALUEs to be canonicalized against them,
which is what this patch implements.  I've not set PRESERVED_VALUE_P
on the SP_DERIVED_VALUE_P at the creation time, because whether a VALUE
is preserved or not is something that affects var-tracking decisions quite a
lot and we shouldn't set it blindly on other VALUEs.

Or, to avoid the repetitive code, should I introduce
static bool
cselib_useless_value_p (cselib_val *v)
{
  return (v->locs == 0
	  && !PRESERVED_VALUE_P (v->val_rtx)
	  && !SP_DERIVED_VALUE_P (v->val_rtx)));
}
predicate and use it in those 6 spots?

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

	PR rtl-optimization/94468
	* cselib.c (references_value_p): Formatting fix.
	(cselib_useless_value_p): New function.
	(discard_useless_locs, discard_useless_values,
	cselib_invalidate_regno_val, cselib_invalidate_mem,
	cselib_record_set): Use it instead of
	v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx).

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

My recent protected_set_expr_location changes work well when
that function is called unconditionally, but as the testcase shows, the C++
FE has a few spots that do:
  if (!EXPR_HAS_LOCATION (stmt))
    protected_set_expr_location (stmt, locus);
or similar.  Now, if we have for -g0 stmt of some expression that can
have location and has != UNKNOWN_LOCATION, while -g instead has
a STATEMENT_LIST containing some DEBUG_BEGIN_STMTs + that expression with
that location, we don't call protected_set_expr_location in the -g0 case,
but do call it in the -g case, because on the STATEMENT_LIST
!EXPR_HAS_LOCATION.
The following patch introduces a helper function which digs up the single
expression of a STATEMENT_LIST and uses that expression in the
EXPR_HAS_LOCATION check (plus changes protected_set_expr_location to
also use that helper).

Or do we want a further wrapper, perhaps C++ FE only, that would do this
protected_set_expr_location_if_unset (stmt, locus)?

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

	PR debug/94441
	* tree-iterator.h (expr_single): Declare.
	* tree-iterator.c (expr_single): New function.
	* tree.h (protected_set_expr_location_if_unset): Declare.
	* tree.c (protected_set_expr_location): Use expr_single.
	(protected_set_expr_location_if_unset): New function.

	* parser.c (cp_parser_omp_for_loop): Use
	protected_set_expr_location_if_unset.
	* cp-gimplify.c (genericize_if_stmt, genericize_cp_loop): Likewise.

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

	PR rtl-optimization/92264
	* config/stormy16/stormy16.c (xstormy16_preferred_reload_class): Handle
	reloading of auto-increment addressing modes.

The following testcase ICEs, because for parallel combined with some
other construct we initialize the omp_parallel_combined_clauses pointer
and expect the construct combined with it to clear it after it no longer
needs it, but OMP_MASTER didn't do that.

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

	PR c++/94477
	* pt.c (tsubst_expr) <case OMP_MASTER>: Clear
	omp_parallel_combined_clauses.

	* g++.dg/gomp/pr94477.C: New test.

	* generic-morestack.c: On GNU/Linux use __mmap/__munmap rather
	than mmap/munmap, to avoid hooks.

commit 16ed2601
Author: H.J. Lu <hongjiu.lu@intel.com>
Date:   Wed May 15 15:26:19 2019 +0000

    i386: Emulate MMX pshufb with SSE version

has

+(define_insn_and_split "ssse3_pshufbv8qi3"
+  [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
+  (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
+           (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yv")]
+          UNSPEC_PSHUFB))
+   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]
                                       ^^^  There are earlyclobber.
+  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
+  "@
+   pshufb\t{%2, %0|%0, %2}
+   #
+   #"
+  "TARGET_MMX_WITH_SSE && reload_completed"
+  [(set (match_dup 3) (match_dup 5))
+   (set (match_dup 3)
+  (and:V4SI (match_dup 3) (match_dup 2)))
+   (set (match_dup 0)
+  (unspec:V16QI [(match_dup 1) (match_dup 4)] UNSPEC_PSHUFB))]

If input register operand 2 is dead after this insn, RA may choose it
as scratch operand.  Since it isn't marked as earlyclobber, operand 2
becomes unused after split and then it gets optimized out.  Mark scratch
operand as earlyclobber fixes the issue.

gcc/

	PR target/94467
	* config/i386/sse.md (ssse3_pshufbv8qi3): Mark scratch operand
	as earlyclobber.

gcc/testsuite/

	PR target/94467
	* gcc.target/i386/pr94467-1.c: New test.
	* gcc.target/i386/pr94467-2.c: Likewise.

	PR rtl-optimization/92264
	* config/m32r/m32r.c (m32r_output_block_move): Properly account for
	post-increment addressing of source operands as well as residuals
	when computing any adjustments to the input pointer.

In https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00576.html the builtin
handling was changed so that OPTION_MASK_ISA_MMX | OPTION_MASK_ISA_SSE
etc. in i386-builtin.def means we require both mmx and sse, not just one of
those, and later on for other option combinations very similar rule has
been clarified, with a few exceptions that ix86_expand_builtin lists
(SSE | 3DNOW_A, SSE4_2 | CRC32 and FMA | FMA4 are one or the other).
The above mentioned patch also added OPTION_MASK_ISA_MMX to a few insns
that in the ISA documents are documented e.g. only requiring SSE2 or SSSE3
etc. CPUID, but because those builtins take or return V2SI or similar
MMX-ish arguments, we can't really support those builtins in functions that
have MMX disabled.
Now, during the TARGET_MMX_WITH_SSE changes,
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01479.html
and
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01084.html
actually changed this; it added | OPTION_MASK_ISA_SSE2 to builtins
that were formerly OPTION_MASK_ISA_MMX only, but didn't touch the builtins
that were already using OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX
for something different (both options must be enabled).
This causes e.g. ICE on the following testcase, because the builtins are
now enabled even with just -mmmx -mno-sse2, even when they (those changed in
2017) require SSE2.
The following patch instead reverts the above two 2019-ish changes (except
for header/testsuite changes), and instead treats OPTION_MASK_ISA_MMX
requirement in bdesc/.isa specially, as being satisfied by either
TARGET_MMX (no changes really needed for that), or by TARGET_MMX_WITH_SSE.
This achieves what the two 2019-ish patches want to do, that the
OPTION_MASK_ISA_MMX only builtins are enabled not just with -mmmx, but also
with -m64 -msse2, and for the other builtins that require MMX and something
else will either require -mmmx and that some other ISA, or -m64 -msse2 and
that other ISA, but -mmmx will not enable builtins that need something more
than OPTION_MASK_ISA_MMX only.
The i386-builtins.c changes that aren't reversion of the two patches try to
make sure that in .isa we still record OPTION_MASK_ISA_MMX for builtins that
have that requirement, so that it is in the end only ix86_expand_builtin
that decides if the builtin is ok or not and the rest of code just decides
if it is the right time to declare the builtin already or if it should be
deferred.

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

	PR target/94461
	* config/i386/i386-expand.c (ix86_expand_builtin): If
	TARGET_MMX_WITH_SSE without TARGET_MMX and bisa contains
	OPTION_MASK_ISA_MMX, clear OPTION_MASK_ISA_MMX and set
	OPTION_MASK_ISA_SSE2 in bisa.  Revert 2019-05-17 and 2019-05-15
	changes.
	* config/i386/i386-builtins.c (def_builtin): If mask includes
	OPTION_MASK_ISA_MMX and TARGET_MMX_WITH_SSE, consider it satisfied.
	(ix86_add_new_builtins): For TARGET_64BIT, consider
	OPTION_MASK_ISA_SSE2 enabled in isa as satisfying OPTION_MASK_ISA_MMX
	requirement.
	(ix86_init_tm_builtins): If TARGET_MMX_WITH_SSE consider
	OPTION_MASK_ISA_MMX as satisfied.
	(bdesc_tm): Revert 2019-05-15 changes.
	(ix86_init_mmx_sse_builtins): Likewise.
	* config/i386/i386-builtin.def: Likewise.

	* gcc.target/i386/pr94461.c: New test.

In this testcase, when we do a pack expansion of count_better_mins<nums>,
nums appears both in the definition of count_better_mins and as its template
argument.  The intent is that we get a expansion over pairs of elements of
the pack, i.e. less<2,2>, less<2,7>, less<7,2>, ....  But if we substitute
into the definition of count_better_mins when parsing the template, we end
up with sum<less<nums,nums>...>, which never gives us less<2,7>.  We could
deal with this by somehow marking up the use of 'nums' as an argument for
'num', but it's simpler to mark the alias as complex, so we need to
instantiate it later with all its arguments rather than replace it early
with its expansion.

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

	PR c++/91966
	* pt.c (complex_pack_expansion_r): New.
	(complex_alias_template_p): Use it.

The following testcase is miscompiled, because the AVX2 patterns don't
describe correctly what the insn does.  E.g. vphaddd with %ymm* operands
(the second pattern) instruction as per:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi32&expand=2941
does { a0+a1, a2+a3, b0+b1, b2+b3, a4+a5, a6+a7, b4+b5, b6+b7 }
but our RTL pattern did
     { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7 }
where the first and last 64 bits are the same and two middle 64 bits
swapped.
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi16&expand=2939
similarly, insn does:
     { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7,
       a8+a9, a10+a11, a12+a13, a14+a15, b8+b9, b10+b11, b12+b13, b14+b15 }
but RTL pattern did
     { a0+a1, a2+a3, a4+a5, a6+a7, a8+a9, a10+a11, a12+a13, a14+a15,
       b0+b1, b2+b3, b4+b5, b6+b7, b8+b9, b10+b11, b12+b13, b14+b15 }
again, first and last 64 bits are the same and the two middle 64 bits
swapped.

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

	PR target/94460
	* config/i386/sse.md (avx2_ph<plusminus_mnemonic>wv16hi3,
	avx2_ph<plusminus_mnemonic>dv8si3): Fix up RTL pattern to do
	second half of first lane from first lane of second operand and
	first half of second lane from second lane of first operand.

	* gcc.target/i386/avx2-pr94460.c: New test.

The fix for PR c++/90711 also fixed this PR.

gcc/testsuite/ChangeLog:

	PR c++/93211
	PR c++/90711
	* g++.dg/template/koenig11.C: New test.

When committing my last patch I accidentally removed -mfpu=auto from the following tests. This puts it back.

testsuite/ChangeLog:
2020-04-03  Andre Vieira  <andre.simoesdiasvieira@arm.com>

	* gcc.target/arm/mve/intrinsics/mve_vector_float.c: Put -mfpu=auto back.
	* gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise.
	* gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Likewise.
	* gcc.target/arm/mve/intrinsics/mve_vector_int.c: Likewise.
	* gcc.target/arm/mve/intrinsics/mve_vector_int1.c: Likewise.
	* gcc.target/arm/mve/intrinsics/mve_vector_int2.c: Likewise.
	* gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
	* gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
	* gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.

Testing Done:
@IP: I assert this is almost no risk.

Reviewed at http://pdtlreviewboard.cambridge.arm.com/r/12880/

This patch makes sure the rest of the header file is not parsed if MVE is not
supported.  The user should not be including this file if MVE is not supported,
nevertheless making sure it doesn't parse the rest of the header file will
save the user from a huge error output that would be rather useless.

gcc/ChangeLog:
2020-04-03  Andre Vieira  <andre.simoesdiasvieira@arm.com>

        * config/arm/arm_mve.h: Condition the header file on __ARM_FEATURE_MVE.