PR testsuite/94334
	* gcc.dg/lto/pr94271_0.c: Skip for non-x86 targets
	and add ifunc effective target.
	* gcc.target/i386/pr81213-2.c: Add ifunc effective target.

The following testcase FAILs, because gimplify_body adds a GIMPLE_NOP only
when there are no statements in the function and with -g there is a
DEBUG_BEGIN_STMT, so it doesn't add it and due to -fno-tree-dce that never
gets removed afterwards.  Similarly, if the body seq after gimplification
contains some DEBUG_BEGIN_STMTs plus a single gbind, then we could behave
differently between -g0 and -g, by using that gbind as the body in the -g0
case and not in the -g case.
This patch fixes that by ignoring DEBUG_BEGIN_STMTs (other debug stmts can't
appear at this point yet thankfully) during decisions and if we pick the
single gbind and there are DEBUG_BEGIN_STMTs next to it, it moves them into
the gbind.
While debugging this, I found also a bug in the gimple_seq_last_nondebug_stmt
function, for a seq that has a single non-DEBUG_BEGIN_STMT statement
followed by one or more DEBUG_BEGIN_STMTs it would return NULL rather than
the first statement.

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

	PR debug/94281
	* gimple.h (gimple_seq_first_nondebug_stmt): New function.
	(gimple_seq_last_nondebug_stmt): Don't return NULL if seq contains
	a single non-debug stmt followed by one or more debug stmts.
	* gimplify.c (gimplify_body): Use gimple_seq_first_nondebug_stmt
	instead of gimple_seq_first_stmt, use gimple_seq_first_nondebug_stmt
	and gimple_seq_last_nondebug_stmt instead of gimple_seq_first and
	gimple_seq_last to check if outer_stmt gbind could be reused and
	if yes and it is surrounded by any debug stmts, move them into the
	gbind body.

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

The standard says: "A function is user-provided if it is user-declared and
not explicitly defaulted or deleted on its first declaration."
I don't see anything about function templates having different rules here,
but user_provided_p does return true for all TEMPLATE_DECLs.

The following patch fixes it by treating as user-provided only templates
that aren't deleted.

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

	PR c++/81349
	* class.c (user_provided_p): Use STRIP_TEMPLATE instead of returning
	true for all TEMPLATE_DECLs.

	* g++.dg/cpp1z/pr81349.C: New test.

The following testcase FAILs with -fcompare-debug.  The problem is that
the C++ FE initially uses IF_STMTs, tcc_statement which default to
TREE_SIDE_EFFECTS set, but later on is genericized into COND_EXPRs,
tcc_expression which default to TREE_SIDE_EFFECTS ored from all 3 operands.
Furthermore, with -g we emit by default DEBUG_BEGIN_STMTs (TREE_SIDE_EFFECTS
clear) and so end up with a STATEMENT_LIST containing DEBUG_BEGIN_STMT
+ e.g. the IF_STMT, while with -g0 we would end up with just the IF_STMT
alone and in that case there is no STATEMENT_LIST wrapping it.

Now, the STATEMENT_LIST has TREE_SIDE_EFFECTS set to match the IF_STMT,
but if none of the 3 operands (condition and both branches) have
TREE_SIDE_EFFECTS, genericize_if_stmt will replace the IF_STMT with
COND_EXPR without TREE_SIDE_EFFECTS, but with -g only STATEMENT_LIST
wrapping it will keep TREE_SIDE_EFFECTS.  Then during gimplification,
shortcut_cond_expr checks TREE_SIDE_EFFECTS of the operands and as it
is differennt between -g and -g0, will generate different code.

The following patch attempts to fix this by clearing TREE_SIDE_EFFECTS
on STATEMENT_LISTs that initially have it set and contain only
DEBUG_BEGIN_STMT or at most one other statement that lost TREE_SIDE_EFFECTS
during the genericization.

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

	PR c++/94272
	* cp-gimplify.c (cp_genericize_r): Handle STATEMENT_LIST.

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

With this simple patch, on i686-linux and x86_64-linux with -m32 (no change
for -m64), the find_base_term visited_vals.length () > 100 find_base_term
statistics changed (fbt is before this patch, fbt2 with this patch):
for k in '' '1$'; do for i in 32 64; do for j in fbt fbt2; do \
echo -n "$j $i $k "; LC_ALL=C grep ^$i.*"$k" $j | wc -l; done; done; done
fbt 32  5313355
fbt2 32  4229854
fbt 64  217523
fbt2 64  217523
fbt 32 1$ 1296
fbt2 32 1$ 407
fbt 64 1$ 0
fbt2 64 1$ 0
For frame_pointer_needed functions, we need to wait until we see the
fp_setter insn in the prologue at which point we disassociate the fp based
VALUEs from sp based VALUEs, but for !frame_pointer_needed functions,
we IMHO don't need to wait anything.  For ACCUMULATE_OUTGOING_ARGS it isn't
IMHO worth doing anything, as there is a single sp adjustment and so there
is no risk of many thousands deep VALUE chains, but for
!ACCUMULATE_OUTGOING_ARGS the sp keeps changing constantly.

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

	PR rtl-optimization/92264
	* var-tracking.c (add_stores): Call cselib_set_value_sp_based even
	for sp based values in !frame_pointer_needed
	&& !ACCUMULATE_OUTGOING_ARGS functions.

In the testcase for PR94269, widening_mul moves two multiply
instructions from outside the loop to inside
the loop, merging with two add instructions separately.  This
increases the cost of the loop.  Like FMA detection
in the same pass, simply restrict ops to be defined in the same
basic-block to avoid possibly moving multiply
to a different block with a higher execution frequency.

2020-03-26  Felix Yang  <felix.yang@huawei.com>

	PR tree-optimization/94269
	* tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict
	this
	operation to single basic block.

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

gcc/ChangeLog

2020-03-25  Carl Love  <cel@us.ibm.com>

	PR target/93819
	* gcc/config/rs6000/altivec.h:
	Fixed swapped arguments for vec_rlnm define.

The previous commit added two tests which were written by Mike Crowe,
not by me. This fixes the ChangeLog entry.

These tests were supposed to be committed as part of r278904 (aka
b789efea) but I didn't 'git add' them.

	* testsuite/30_threads/shared_timed_mutex/try_lock_until/1.cc: New
	test.
	* testsuite/30_threads/shared_timed_mutex/try_lock_until/2.cc: New
	test.

For C++20 the wait_until members of mutexes and condition variables are
required to be ill-formed if given a clock that doesn't meet the
requirements for a clock type. To implement that requirement this patch
adds static assertions using the chrono::is_clock trait, and defines
that trait.

To avoid expensive checks for the common cases, the trait (and
associated variable template) are explicitly specialized for the
standard clock types.

This also moves the filesystem::__file_clock type from <filesystem> to
<chrono>, so that chrono::file_clock and chrono::file_time can be
defined in <chrono> as required.

	* include/bits/fs_fwd.h (filesystem::__file_clock): Move to ...
	* include/std/chrono (filesystem::__file_clock): Here.
	(filesystem::__file_clock::from_sys, filesystem::__file_clock::to_sys):
	Define public member functions for C++20.
	(is_clock, is_clock_v): Define traits for C++20.
	* include/std/condition_variable (condition_variable::wait_until): Add
	check for valid clock.
	* include/std/future (_State_baseV2::wait_until): Likewise.
	* include/std/mutex (__timed_mutex_impl::_M_try_lock_until): Likewise.
	* include/std/shared_mutex (shared_timed_mutex::try_lock_shared_until):
	Likewise.
	* include/std/thread (this_thread::sleep_until): Likewise.
	* testsuite/30_threads/condition_variable/members/2.cc: Qualify
	slow_clock with new namespace.
	* testsuite/30_threads/condition_variable/members/clock_neg.cc: New
	test.
	* testsuite/30_threads/condition_variable_any/members/clock_neg.cc:
	New test.
	* testsuite/30_threads/future/members/clock_neg.cc: New test.
	* testsuite/30_threads/recursive_timed_mutex/try_lock_until/3.cc:
	Qualify slow_clock with new namespace.
	* testsuite/30_threads/recursive_timed_mutex/try_lock_until/
	clock_neg.cc: New test.
	* testsuite/30_threads/shared_future/members/clock_neg.cc: New
	test.
	* testsuite/30_threads/shared_lock/locking/clock_neg.cc: New test.
	* testsuite/30_threads/shared_timed_mutex/try_lock_until/clock_neg.cc:
	New test.
	* testsuite/30_threads/timed_mutex/try_lock_until/3.cc: Qualify
	slow_clock with new namespace.
	* testsuite/30_threads/timed_mutex/try_lock_until/4.cc: Likewise.
	* testsuite/30_threads/timed_mutex/try_lock_until/clock_neg.cc: New
	test.
	* testsuite/30_threads/unique_lock/locking/clock_neg.cc: New test.
	* testsuite/std/time/traits/is_clock.cc: New test.
	* testsuite/util/slow_clock.h (slow_clock): Move to __gnu_test
	namespace.

2020-03-25  Andrew Stubbs  <ams@codesourcery.com>

	gcc/testsuite/
	* gcc.dg/vect/bb-slp-pr69907.c: Disable the dump scan for amdgcn.
	* lib/target-supports.exp (check_effective_target_vect_unpack):
	Add amdgcn.

    Fix vector-compare-1 regressions on sh4/sh4eb caused by pattern clobbering T reg without expressing that in its RTL.

            PR rtl-optimization/90275
            * config/sh/sh.md (mov_neg_si_t): Clobber the T register in the
            pattern.

Fix vector-compare-1 regressions on sh4/sh4eb caused by pattern clobbering T reg without expressing that in its RTL.

	PR rtl-optimization/90275
	* config/sh/sh.md (mov_neg_si_t): Clobber the T register in the
	pattern.

The following testcase ICEs, because arm_gen_dicompare_reg creates invalid
RTL which then propagates into DEBUG_INSNs and ICEs while handling them.
The problem is that this function emits
(insn 18 17 19 2 (set (reg:CC_DNE 100 cc)
        (compare (ior:SI (ne:SI (subreg:SI (reg:DI 129) 0)
                    (subreg:SI (reg:DI 114 [ _2 ]) 0))
                (ne:SI (subreg:SI (reg:DI 129) 4)
                    (subreg:SI (reg:DI 114 [ _2 ]) 4)))
            (const_int 0 [0]))) "pr94292.c":7:11 325 {*cmp_ior}
     (nil))
and the invalid thing is that the COMPARE has VOIDmode.  Setting a
non-VOIDmode SET_DEST to VOIDmode SET_SRC is only valid if the SET_SRC is
CONST_INT/CONST_DOUBLE.
The following patch fixes it by giving the COMPARE the same mode as it gives
to the SET_DEST cc register.

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

	PR target/94292
	* config/arm/arm.c (arm_gen_dicompare_reg): Set mode of COMPARE to
	mode rather than VOIDmode.

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

gcc/testsuite/ChangeLog:

	PR middle-end/94004
	* gcc.dg/Walloca-larger-than-3.c: New test.
	* gcc.dg/Walloca-larger-than-3.h: New test header.
	* gcc.dg/Wvla-larger-than-4.c: New test.

gcc/ChangeLog:

	PR middle-end/94004
	* gimple-ssa-warn-alloca.c (pass_walloca::execute): Issue warnings
	even for alloca calls resulting from system macro expansion.
	Include inlining context in all warnings.

    g:497498c8 caused lra to cycle
    on some SDmode reloads for power6.  As explained in more detail
    in the PR comments, the problem was a conflict between two target
    hooks: rs6000_secondary_memory_needed_mode required SDmode FPR
    reloads to use DDmode memory (rightly, since using SDmode memory
    wouldn't make progress) but rs6000_can_change_mode_class didn't
    allow FPRs to change from SDmode to DDmode.  Previously lra
    ignored that and changed the mode anyway.

    From what Segher says, it sounds like the "from_size < 8 || to_size < 8"
    check is mostly there for SF<->64-bit subregs, and that SDmode is stored
    in the way that target-independent code expects.  This patch therefore
    allows SD<->DD changes.

    I wondered about checking for SD<->64-bit changes instead, but that
    seemed like an unnecessary generalisation for this stage.

    2020-03-23  Richard Sandiford  <richard.sandiford@arm.com>

    gcc/
            PR target/94254
            * config/rs6000/rs6000.c (rs6000_can_change_mode_class): Allow
            FPRs to change between SDmode and DDmode.

This fixes a false-positive warning from -Wduplicate-cond in the presence of an
if-statement with a non-empty init-statement.  Precisely determining whether a
non-empty init-statement has side effects seems tricky and error-prone, so this
patch takes the route of unconditionally invalidating the condition chain when
it encounters such an if-statement.

gcc/cp/ChangeLog:

	PR c++/94265
	* parser.c (cp_parser_selection_statement) <case RID_IF>: Invalidate the
	current condition chain when the if-statement has a non-empty
	init-statement.

gcc/testsuite/ChangeLog:

	PR c++/94265
	* g++.dg/warn/Wduplicated-cond1.C: New test.

gcc/testsuite/ChangeLog:

	PR tree-optimization/94131
	* gcc.dg/pr94131.c: New test.

gcc/ChangeLog:

	PR tree-optimization/94131
	* gimple-fold.c (get_range_strlen_tree): Fail for variable-length
	types and decls.
	* tree-ssa-strlen.c (get_range_strlen_dynamic): Avoid assuming
	types have constant sizes.

2020-03-25  Sandra Loosemore  <sandra@codesourcery.com>

	gcc/testsuite/
	* gcc.dg/pr92301.c (main): Allow argc to be 0 to support
	embedded targets.

Fix a typo.

gcc/cp/ChangeLog:

2020-03-25  Iain Sandoe  <iain@sandoe.co.uk>

	PR c++/94319
	* coroutines.cc (captures_temporary): Fix a missing dereference.

	PR lto/94259
	* configure.ac: Report error only when --with-zstd
	is used.
	* configure: Regenerate.

As this test produces different code depending on whether
__GCC_HAVE_DWARF2_CFI_ASM macro is defined or not, it is inherently
incompatible with -fcompare-debug, as with
-fcompare-debug -fno-asynchronous-unwind-tables -fno-exceptions
the macro is defined only in the -g case and not otherwise.
The purpose of the macro is to tell when the compiler is emitting
.cfi* directives itself and thus it is desirable that user code uses them in
inline asm as well, so I think it is fine the way it is.
As -fexceptions makes the test pass even in that case because it emits
.cfi* directives, the test actually doesn't FAIL even with
make check-gcc RUNTESTFLAGS='--target_board=unix/-fcompare-debug/-fno-asynchronous-unwind-tables/-fno-exceptions dg.exp=cleanup-13.c'
so the intent of this patch is help Martin and others who do run gcc tests
out of the testsuite with random compiler flags to find out that this is a
known issue.

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

	PR debug/94296
	* gcc.dg/cleanup-13.c: Add a comment that the test is not
	-fcompare-debug compatible with certain other options.

The following patch ICEs due to my recent change r10-6451-gb7b3378f.
Since that patch, for explicit vzeroupper in the sources (when an intrinsic
is used), we start with the *avx_vzeroupper_1 pattern which contains just the
UNSPECV_VZEROUPPER and no sets/clobbers.  The vzeroupper pass then adds some
sets to those, but doesn't add clobbers and finally there is an
&& epilogue_completed splitter that splits this into the *avx_vzeroupper
pattern which has the right number of sets/clobbers (16 on 64-bit, 8 on
32-bit) + the UNSPECV_VZEROUPPER first.
The problem with this testcase on !TARGET_64BIT is that the vzeroupper pass
adds 8 sets to the pattern, i.e. the maximum number, but INSN_CODE stays
to be the one of the *avx_vzeroupper_1 pattern.  The splitter doesn't do
anything here, because it sees the number of rtxes in the PARALLEL already
the right count, but during final we see that the *avx_vzeroupper_1 pattern
has "#" output template and ICE that we forgot to split it.

The following patch fixes it by forcing re-recognition of the insn after we
make the changes to it in ix86_add_reg_usage_to_vzeroupper.  Anything that
will call recog_memoized later on will recog it and find out it is in this
case already *avx_vzeroupper rather than *avx_vzeroupper_1.

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

	PR target/94308
	* config/i386/i386-features.c (ix86_add_reg_usage_to_vzeroupper): Set
	INSN_CODE (insn) to -1 when changing the pattern.

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

	PR target/93274
	PR ipa/94271
	* config/i386/i386-features.c (make_resolver_func): Drop
	public flag for resolver.
	* config/rs6000/rs6000.c (make_resolver_func): Add comdat
	group for resolver and drop public flag if possible.
	* multiple_target.c (create_dispatcher_calls): Drop unique_name
	and resolution as we want to enable LTO privatization of the default
	symbol.
	PR target/93274
	PR ipa/94271
	* gcc.target/i386/pr81213-2.c: New test.
	* gcc.target/i386/pr81213.c: Add additional source.
	* gcc.dg/lto/pr94271_0.c: New test.
	* gcc.dg/lto/pr94271_1.c: New test.

	PR lto/94259
	* configure.ac: Respect --without-zstd and report
	error when we can't find header file with --with-zstd.
	* configure: Regenerate.

These 3 tests use compiler_options() function,
which is inherently incompatible with -fcompare-debug compilation, as it
emits into a string literal in the assembly the exact f951 command line
options, which differs between the two compilations with -fcompare-debug,
where one has -gtoggle and -fcompare-debug-second options added and
different -fdump-final-insns= option argument.

The following patch adds dg-skip-if directives, so that these tests are
ignored during
make check-gfortran RUNTESTFLAGS='--target_board=unix/-fcompare-debug'

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

	PR debug/94280
	* gfortran.dg/iso_c_binding_compiler_1.f90: Add dg-skip-if for
	-fcompare-debug.
	* gfortran.dg/iso_c_binding_compiler_3.f90: Likewise.
	* gfortran.dg/unlimited_polymorphic_31.f03: Likewise.

Using undeclared symbol k in an expression in the following
array constructor results in an ICE:

    print *, [real(x(k))]

If the call to the intrinsic is not in a constructor a no IMPLICIT
type error is reported and the ICE does not occur.

Matching on an expression instead of an initialisation express an
and not converting a MATCH_ERROR return value into MATCH_NO results
in the no IMPLICIT error and no ICE.

Note: Steven G. Kargl  <kargl@gcc.gnu.org> is the author of the
changes except for the test cases.

gcc/fortran/ChangeLog:

	PR fortran/93484
	* match.c (gfc_match_type_spec): Replace gfc_match_init_expr with
	gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR.

gcc/testsuite

	PR fortran/93484
	* gfortran.dg/pr93484_1.f90: New test.
	* gfortran.dg/pr93484_2.f90: New test.

The following testcase is miscompiled, because output_constructor doesn't
output the initializer correctly.  The FE creates {[1...2] = 9} in this
case, and we emit .long 9; long 9; .zero 8 instead of the expected
.zero 8; .long 9; .long 9.  If the CONSTRUCTOR is {[1] = 9, [2] = 9},
output_constructor_regular_field has code to notice that the current
location (local->total_bytes) is smaller than the location we want to write
to (1*sizeof(elt)) and will call assemble_zeros to skip those.  But
RANGE_EXPRs are handled by a different function which didn't do this,
so for RANGE_EXPRs we emitted them properly only if local->total_bytes
was always equal to the location where the RANGE_EXPR needs to start.

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

	PR middle-end/94303
	* varasm.c (output_constructor_array_range): If local->index
	RANGE_EXPR doesn't start at the current location in the constructor,
	skip needed number of bytes using assemble_zeros or assert we don't
	go backwards.

	PR middle-end/94303
	* g++.dg/torture/pr94303.C: New test.

As mentioned in the PR, we don't guarantee DECL_UID to be the same between
corresponding decls in -g and -g0 builds, -g can create more decls and all
that is guaranteed is that the DECL_UIDs of the corresponding decls compare
the same.
The following testcase gets a -fcompare-debug failure because these
functions use DECL_UID as the number in ASM_FORMAT_PRIVATE_NAME.

The patch fixes it by using just a sequential number there instead.
I don't think this can be called during PCH writing, this only happens for
non-public decls and the C/C++ FEs shouldn't mangling those at that point
(furthermore C++ FE uses a different set_decl_assembler_name hook and this
one is something only the gimplifier calls on C.NNNN temporaries.

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

	PR c++/94223
	* langhooks.c (lhd_set_decl_assembler_name): Use a static ulong
	counter instead of DECL_UID.

	* lto-lang.c (lto_set_decl_assembler_name): Use a static ulong
	counter instead of DECL_UID.

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

The following testcase is miscompiled, because there is a buffer overflow
in push_partial_def in the little-endian case when working 64-byte vectors.
The code computes the number of bytes we need in the BUFFER: NEEDED_LEN,
which is rounded up number of bits we need.  Then the code
native_encode_expr each (partially overlapping) pd into THIS_BUFFER.
If pd.offset < 0, i.e. the pd.rhs store starts at some bits before the
window we are interested in, we pass -pd.offset to native_encode_expr and
shrink the size already earlier:
      HOST_WIDE_INT size = pd.size;
      if (pd.offset < 0)
        size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
On this testcase, the problem is with a store with pd.offset > 0,
in particular pd.offset 256, pd.size 512, i.e. a 64-byte store which doesn't
fit into entirely into BUFFER.
We have just:
          size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
in this case for little-endian, which isn't sufficient, because needed_len
is 64, the entire BUFFER (except of the last extra byte used for shifting).
native_encode_expr fills the whole THIS_BUFFER (again, except the last extra
byte), and the code then performs memcpy (BUFFER + 32, THIS_BUFFER, 64);
which overflows BUFFER and as THIS_BUFFER is usually laid out after it,
overflows it into THIS_BUFFER.
The following patch fixes it by for pd.offset > 0 making sure size is
reduced too.  For big-endian the code does things differently and already
handles this right.

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

	PR tree-optimization/94300
	* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): If pd.offset
	is positive, make sure that off + size isn't larger than needed_len.

	* gcc.target/i386/avx512f-pr94300.c: New test.

> > This patch caused:
> >
> > gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c -O3 -g -fno-tree-dce -c
> > during GIMPLE pass: ifcvt
> > /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c: In function ‘broken030599’:
> > /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/990625-2.c:2:1: internal compiler error: Segmentation fault
>
> Likely
>
>   /* Delete dead statements.  */
>   gsi = gsi_start_bb (bb);
>   while (!gsi_end_p (gsi))
>     {
>
> needs to instead work back-to-front for debug stmt adjustment to work

Indeed, that seems to work.

2020-03-25  Richard Biener  <rguenther@suse.de>
	    Jakub Jelinek  <jakub@redhat.com>

	PR debug/94283
	* tree-if-conv.c (ifcvt_local_dce): Delete dead statements backwards.

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

Co-authored-by: Richard Biener <rguenther@suse.de>

2020-03-24  Sandra Loosemore  <sandra@codesourcery.com>

	gcc/testsuite/
	* gcc.dg/analyzer/sigsetjmp-5.c: Require sigsetjmp support.
	* gcc.dg/analyzer/sigsetjmp-6.c: Likewise.
	* lib/target-supports.exp (check_effective_target_sigsetjmp): New.

Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it.  In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it.  So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR.  Before
the convert_like change it got *S::operator long int &(&b) whose type
is long int but now it gets IMPLICIT_CONV_EXPR<long int&>(b) whose type
is a reference type.  But the !MAYBE_CLASS_TYPE_P switch doesn't handle
reference types and so we complain.

Fixed by calling convert_from_reference on the result of convert_like.

	PR c++/94190 - wrong no post-decrement operator error in template.
	* call.c (convert_like_real): Use convert_from_reference on the result.

	* g++.dg/conversion/op7.C: New test.

It would have been trivial to make the error for non-bool constraint in
satisfy_atom unconditional, but that didn't give context for the error or
printing with the dependent form and template arguments.  So I changed a
couple of places so that, when a hard error is encountered during quiet
substitution/satisfaction, we go through again noisily; this builds up the
necessary context.

The similar change to tsubst_nested_requirement does not build up the
necessary context; rather than try to fix that now I changed
get_constraint_error_location to give up and use input_location if there's
no CONSTR_CONTEXT.  In the case of concepts-pr67697.C, we still have a good
source location because the NESTED_REQ has a correct EXPR_LOCATION, but this
patch doesn't improve context printing for this case as it does for the
above.

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

	PR c++/94186
	* constraint.cc (constraint_satisfaction_value): Repeat noisily on
	error.
	(tsubst_nested_requirement): Likewise.
	(get_constraint_error_location): Allow missing context.
	(diagnose_atomic_constraint): Diagnose non-bool constraint here.
	(satisfy_atom): Not here.  Only diagnose non-constant when noisy.

While looking at PR94186 I also noticed this regression; if a non-type
template parameter uses a type parameter in its type, we need to map both
template parameters.

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

	* pt.c (any_template_parm_r): Look into the type of a non-type
	template parm.

In the testcase for PR94186, we have a SCOPE_REF with no location even
though at one point it was in a cp_expr which had a location.  So let's make
the cp_expr constructor that takes a location apply it to the expression
when possible.

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

	* cp-tree.h (cp_expr): When constructing from an expr and a
	location, call protected_set_expr_location.

Switch to arm_fp_dp_ok effective-target in tests that require
double-precision support from the FPU.

2020-03-24  Christophe Lyon  <christophe.lyon@linaro.org>

	gcc/testsuite/
	* gcc/arm/vfp-1.c: Use arm_fp__ok effective-target.
	* gcc.target/arm/vfp-ldmdbd.c: Likewise.
	* gcc.target/arm/vfp-ldmiad.c: Likewise.
	* gcc.target/arm/vfp-stmdbd.c: Likewise.
	* gcc.target/arm/vfp-stmiad.c: Likewise.
	* gcc.target/arm/vnmul-1.c: Likewise.
	* gcc.target/arm/vnmul-3.c: Likewise.
	* gcc.target/arm/vnmul-4.c: Likewise.

Parts of the cmp-2.c test rely on double-precision support, making the
test fail on targets where the FPU supports single-precision only.

Split the test into single-precision (cmp-2.c) and double-precision
tests (cmp-3.c).

2020-03-24  Christophe Lyon  <christophe.lyon@linaro.org>

	gcc/testsuite/
	* gcc.target/arm/cmp-2.c: Move double-precision tests to...
	* gcc.target/arm/cmp-3.c: ...here (new file)