Although the note in the text [expr.await] / 5.1.1 is not normative,
it is asserted by users that an implementation that is unable to
perform unlimited symmetric transfers is not terribly useful.

This relates to the following circumstance:

try {
 users-function-body:
 {
    ....
    { some suspend context
      continuation_handle = await_suspend (another handle);
      continuation_handle.resume ();
      'return' (actually a suspension operation).
    }
  }
} catch (...) {}

The call to 'continuation_handle.resume ()' needs to be a tail-
call in order that an arbitrary number of coroutines can be handled
in this manner.  There are two issues with this:

1. That the user's function body is wrapped in a try/catch block and
   one cannot tail-call from within those.

2. That GCC doesn't usually produce tail-calls when the optimisation
   level is < O2.

After considerable discussion at WG21 meetings, it has been determined
that the intent is that the operation behaves as if the resume call is
executed in the context of the caller.

So, we can remap the fragment above like this:

{
  void_coroutine_handle continuation;

  try {
   users-function-body:
   {
      ....
      { some suspend context
        continuation = await_suspend (another handle);
        <scope exit without cleanup> symmetric_transfer;
      }
    }
  } catch (...) {}

symmetric_transfer:
  continuation.resume(); [tail call] [must tail call]
}

Thus we take the call outside the try-catch block which solves
issue (1) and mark it as a tail call and as "must tail call" for
correctness which solves (2).

As bonuses, since we no longer need to differentiate handle types
returned from await_suspend() methods, nor do we need to keep them
in the coroutine frame, since they are ephemeral, we save entries in
the frame and reduce some code too.

gcc/cp/ChangeLog:

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

	* coroutines.cc (coro_init_identifiers): Initialize an identifier
	for the cororoutine handle 'address' method name.
	(struct coro_aw_data): Add fields to cover the continuations.
	(co_await_expander): Determine the kind of await_suspend in use.
	If we have the case that returns a continuation handle, then save
	this and make the target for 'scope exit without cleanup' be the
	continuation resume label.
	(expand_co_awaits): Remove.
	(struct suspend_point_info): Remove fields that kept the returned
	await_suspend handle type.
	(transform_await_expr): Remove code tracking continuation handles.
	(build_actor_fn): Add the continuation handle as an actor-function
	scope var.  Build the symmetric transfer continuation point. Call
	the tree walk for co_await expansion directly, rather than via a
	trivial shim function.
	(register_await_info): Remove fields tracking continuation handles.
	(get_await_suspend_return_type): Remove.
	(register_awaits): Remove code tracking continuation handles.
	(morph_fn_to_coro): Remove code tracking continuation handles.

gcc/testsuite/ChangeLog:

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

	* g++.dg/coroutines/torture/co-ret-09-bool-await-susp.C: Amend
	to n4849 behaviour.
	* g++.dg/coroutines/torture/symmetric-transfer-00-basic.C: New
	test.

The standard now calls up a revised mechanism to handle exceptions
where exceptions thrown by the await_resume () method of the
initial suspend expression are considered in the same manner as
exceptions thrown by the user-authored function body.

This implements [dcl.fct.def.coroutine] / 5.3.

gcc/cp/ChangeLog:

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

	* coroutines.cc (co_await_expander): If we are expanding the
	initial await expression, set a boolean flag to show that we
	have now reached the initial await_resume() method call.
	(expand_co_awaits): Handle the 'initial await resume called' flag.
	(build_actor_fn): Insert the initial await expression into the
	start of the user-authored function-body. Handle the 'initial await
	resume called' flag.
	(morph_fn_to_coro): Initialise the 'initial await resume called'
	flag.  Modify the unhandled exception catch clause to recognise
	exceptions that occur before the initial await_resume() and re-
	throw them.

gcc/testsuite/ChangeLog:

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

	* g++.dg/coroutines/torture/exceptions-test-01-n4849-a.C: New test.

	* include/std/chrono (chrono::days, chrono::weeks, chrono::years)
	(chrono::months, chrono::sys_days, chrono::local_t)
	(chrono::local_time, chrono::local_seconds, chrono::local_days):
	Define for C++20.
	(chrono::time_point): Add missing static assert.
	* testsuite/20_util/time_point/requirements/duration_neg.cc: New test.
	* testsuite/std/time/clock/file/overview.cc: New test.
	* testsuite/std/time/clock/file/members.cc: New test.
	* testsuite/std/time/syn_c++20.cc: New test.

The recent patch to convert all thumb1 code in libgcc to unified syntax
ommitted the conditional code that is used only when building the library
for minimal size.  This patch fixes this case.

I've also fixed the COND macro so that a single definition is always used
that is for unified syntax.  This eliminates a warning that is now being
seen from the assembler when compiling the ieee fp support code.

	PR target/94220
	* config/arm/lib1funcs.asm (COND): Use a single definition for
	unified syntax.
	(aeabi_uidivmod): Unified syntax when optimizing Thumb for size.
	(aeabi_idivmod): Likewise.
	(divsi3_skip_div0_test): Likewise.

	* gcc.target/i386/pr81213.c: Do not scan assembler
	and add one missing PR entry.

The following testcase FAILs since recently when the C++ FE started calling
protected_set_expr_location more often.
With -g, it is called on a STATEMENT_LIST that contains a DEBUG_BEGIN_STMT
and CLEANUP_POINT_EXPR, and as STATEMENT_LISTs have !CAN_HAVE_LOCATION_P,
nothing is set.  Without -g, it is called instead on the CLEANUP_POINT_EXPR
directly and changes its location.

The following patch recurses on the single non-DEBUG_BEGIN_STMT statement
of a STATEMENT_LIST if any to make the two behave the same.

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

	PR debug/94323
	* tree.c (protected_set_expr_location): Recurse on STATEMENT_LIST
	that contains exactly one non-DEBUG_BEGIN_STMT statement.

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

	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.