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)

Some tests require double-precision support, but the existing
arm_fp_ok effective-target only checks if hardware floating-point is
available, not what level. So this patch adds a new arm_fp_dp_ok
effective-target to check that double-precision is supported.

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

	gcc/
	* doc/sourcebuild.texi (ARM-specific attributes): Add
	arm_fp_dp_ok.
	(Features for dg-add-options): Add arm_fp_dp.

	gcc/testsuite/
	* lib/target-supports.exp
	(check_effective_target_arm_fp_dp_ok_nocache): New.
	(check_effective_target_arm_fp_dp_ok): New.
	(add_options_for_arm_fp_dp): New.

	2020-03-24  John David Anglin  <danglin@gcc.gnu.org>

	PR lto/94249
	* config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Define __BIG_ENDIAN__.

	PR libgomp/81689
	* lto.c (offload_handle_link_vars): Propagate TREE_PUBLIC state.

	PR libgomp/81689
	* omp-offload.c (omp_finish_file): Fix target-link handling if
	targetm_common.have_named_sections is false.

	PR libgomp/81689
	* testsuite/libgomp.c/target-link-1.c: Remove xfail.

	PR lto/94249
	* plugin-api.h: Add more robust endianess detection.

The following testcase ICEs, because these expanders will happily create
a SImode 0x80000000 CONST_INT, which is not valid RTL, as CONST_INTs need to
be sign extended from the mode precision to full HWI.

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

	PR target/94286
	* config/arm/arm.md (subvdi4, usubvsi4, usubvdi4): Use gen_int_mode
	instead of GEN_INT.

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

The following testcase FAILs with -fcompare-debug.  The problem is that
create_iv behaves differently when inserting after into an empty bb (in that
case sets location to goto_locus), or when inserting before gsi_end_p (i.e.
at the end of bb; in that case it will not set location, otherwise it will
set it to the location of next stmt).
This isn't -fcompare-debug friendly, because if inserting after and the
bb contains only debug stmts, then the location will not be set with -g
and will be with -g0, or when inserting before, the location might either
be set from the following debug stmt rather than some non-debug stmt after
that, or might not be set with -g0 if it is to be inserted at the end of bb,
while with -g would be set to location of debug stmt.

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

	PR debug/94285
	* tree-ssa-loop-manip.c (create_iv): If after, set stmt location to
	e->goto_locus even if gsi_bb (*incr_pos) contains only debug stmts.
	If not after and at *incr_pos is a debug stmt, set stmt location to
	location of next non-debug stmt after it if any.

	* gfortran.dg/pr94285.f90: New test.

The following testcase shows -fcompare-debug bugs in ifcvt_local_dce,
where the decisions what statements are needed is based also on debug stmt
operands, which is wrong.
So, this patch makes sure to never add debug stmt to the worklist, or never
add an assign to worklist just because it is used in a debug stmt in another
bb.

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

	PR debug/94283
	* tree-if-conv.c (ifcvt_local_dce): For gimple debug stmts, just set
	GF_PLF_2, but don't add them to worklist.  Don't add an assigment to
	worklist or set GF_PLF_2 just because it is used in a debug stmt in
	another bb.  Formatting improvements.

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

The following testcase FAILs with -fcompare-debug, but not because -g vs.
-g0 would make a difference, but because the second compilation is done with
-w in order not to emit warnings twice and -w seems to affect the *.gkd dump
content.
This is because TREE_NO_WARNING flag, or warn_unused_function does affect
not just whether a warning/pedwarn is printed, but also whether we set
TREE_PUBLIC on such decls.
The following patch makes sure we set it regardless of anything warning
related (TREE_NO_WARNING or warn_unused_function).

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

	PR debug/94277
	* cgraphunit.c (check_global_declaration): For DECL_EXTERNAL and
	non-TREE_PUBLIC non-DECL_ARTIFICIAL FUNCTION_DECLs, set TREE_PUBLIC
	regardless of whether TREE_NO_WARNING is set on it or whether
	warn_unused_function is true or not.

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

	PR rtl-optimization/90275
	PR target/94238
	PR target/94144
	* simplify-rtx.c (comparison_code_valid_for_mode): New function.
	(simplify_logical_relational_operation): Use it.

	PR target/94144
	PR target/94238
	* gcc.c-torture/compile/pr94144.c: New test.
	* gcc.c-torture/compile/pr94238.c: New test.

In this PR we're emitting -Wnoexcept warnings about potentially-throwing NSDMIs
when computing the noexcept specification of a class's defaulted default
constructor.  Although these warnings are in some sense valid, this patch takes
the route of suppressing them, because:

  1. the warning message is confusing in its current form;
  2. warning for 'struct C { B b = B(); };' but not for 'struct C { B b; };'
     is inconsistent; and
  3. emitting a warning here arguably doesn't fall under the umbrella of
     -Wnoexcept, whose documentation says it warns only when a
     noexcept-expression evaluates to false, but there are no
     noexcept-expressions here.

gcc/cp/ChangeLog:

	PR c++/93805
	* except.c (maybe_noexcept_warning): Add TODO comment.
	* method.c (walk_field_subobs): Pass tf_none to expr_noexcept_p.

gcc/testsuite/ChangeLog:

	PR c++/93805
	* g++.dg/warn/Wnoexcept2.C: New test.

As the testcases shows, the -Wconversion warning behaves quite differently
when -fsanitize=undefined vs. when not sanitizing, but in the end it is
not something specific to sanitizing, if a user uses
  return static_cast<uc>(static_cast<uc>((d++, a) << 1U) | b) | c;
instead of
  return static_cast<uc>(static_cast<uc>(a << 1U) | b) | c;
and thus there is some COMPOUND_EXPR involved, cp_build_binary_op behaves
significantly different, e.g. shorten_binary_op will have different result
(uc for the case without COMPOUND_EXPR, int with it), but it isn't limited
to that.

> How about improving get_narrower to handle COMPOUND_EXPR?  I'd think that
> would do the trick without affecting evaluation order.

Not completely, had to change also warnings_for_convert_and_check, but with
that it works.  The float-cast-overflow* changes are needed because now with
-O1+ we emit lots of -Woverflow warnings on the testcase, but we do emit
those warnings on the testcase even when compiling just with -O1 and without
-fsanitize=float-cast-overflow, so it seems to me a change in the right
direction, having -fsanitize= or explicit comma expressions smaller effect
on the warnings that are emitted.

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

	PR c++/91993
	* tree.c (get_narrower): Handle COMPOUND_EXPR by recursing on
	ultimate rhs and if returned something different, reconstructing
	the COMPOUND_EXPRs.

	* c-warn.c (warnings_for_convert_and_check): For expr and/or
	result being COMPOUND_EXPRs, skip to ultimate rhs.

	* g++.dg/warn/Wconversion-pr91993.C: New test.
	* g++.dg/ubsan/pr91993.C: New test.
	* c-c++-common/ubsan/float-cast-overflow-1.c: Add -Wno-overflow
	to dg-options.
	* c-c++-common/ubsan/float-cast-overflow-2.c: Likewise.
	* c-c++-common/ubsan/float-cast-overflow-4.c: Likewise.

Unfortunately the patch broke
+FAIL: gcc.dg/pr20245-1.c (internal compiler error)
+FAIL: gcc.dg/pr20245-1.c (test for excess errors)
+FAIL: gcc.dg/pr28419.c (internal compiler error)
+FAIL: gcc.dg/pr28419.c (test for excess errors)
on some targets (and under valgrind on the rest of them).

Those functions don't have the opening { and so c_parser_compound_statement
returned error_mark_node before initializing *endlocp.
So, either we can initialize it in that case too:
--- gcc/c/c-parser.c    2020-03-20 22:09:39.659411721 +0100
+++ gcc/c/c-parser.c    2020-03-21 09:36:44.455705261 +0100
@@ -5611,6 +5611,8 @@ c_parser_compound_statement (c_parser *p
         if we have just prepared to enter a function body.  */
       stmt = c_begin_compound_stmt (true);
       c_end_compound_stmt (brace_loc, stmt, true);
+      if (endlocp)
+       *endlocp = brace_loc;
       return error_mark_node;
     }
   stmt = c_begin_compound_stmt (true);
or perhaps simpler initialize it to the function_start_locus at the
beginning and have those functions without { have function_start_locus ==
function_end_locus like the __GIMPLE functions (where propagating the
closing } seemed too difficult).

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

	PR gcov-profile/94029
	PR c/94239
	* c-parser.c (c_parser_declaration_or_fndef): Initialize endloc to
	the function_start_locus location.  Don't do that afterwards for the
	__GIMPLE body parsing.

gcc/ChangeLog:

2020-03-23  Lewis Hyatt  <lhyatt@gmail.com>

	* opts.c (print_filtered_help): Improve the help text for alias options.