I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
and x86.

Created on master with make new-abi-baseline on i386-pc-solaris2.11 and
sparc-sun-solaris2.11, bootstrapped on gcc-10 branch without regressions.

	* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
	* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
	Likewise.
	* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
	* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
	Likewise.

	* doc/xml/manual/abi.xml (abi.versioning.history): Document library
	versions for GCC 9.[123] and 10.1 releases.
	* doc/html/*: Regenerate.

On Wed, May 06, 2020 at 10:49:13AM +0200, Rainer Orth wrote:
> I just remembered that the libstdc++ ABI baselines haven't been updated
> for the GCC 10 release yet.  This patch corrects this for Solaris/SPARC
> and x86.

Oops, here are the updates from Fedora packages built during the weekend.

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

	* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
	* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.

This patch updates install.texi for GCC 10 on Solaris.  It includes some
general cleanup and updates and includes a couple of caveats, some of
them found when testing GCC 10.1.0 RC1 with only the bundled tools.

The reference to TGCware on the binaries page is gone because they only
provide binaries up to Solaris 9.

The note about configuring 64-bit Solaris/SPARC compilers with
--build=sparcv9-sun-solaris2.11 became necessary because upstream
config.guess silently reverted my patch to automatically detect this.  We
already had a bug report about a comparison failure caused by this issue.

Tested with make doc/gccinstall.info and doc/gccinstall.pdf and
inspection of the resulting files.

	* doc/install.texi: Replace Sun with Solaris as appropriate.
	(Tools/packages necessary for building GCC, Perl version between
	5.6.1 and 5.6.24): Remove Solaris 8 reference.
	(Installing GCC: Binaries, Solaris 2 (SPARC, Intel)): Remove
	TGCware reference.
	(Specific, i?86-*-solaris2*): Update version references for
	Solaris 11.3 and later.  Remove gas 2.26 caveat.
	(Specific, *-*-solaris2*): Update version references for
	Solaris 11.3 and later.  Remove boehm-gc reference.
	Document GMP, MPFR caveats on Solaris 11.3.
	(Specific, sparc-sun-solaris2*): Update Solaris 9 references.
	(Specific, sparc64-*-solaris2*): Likewise.
	Document --build requirement.

I've recently tested i386-pc-solaris2.11 bootstrap on Solaris 11/x86
with only the bundled tools (using /usr/gnu/bin/as from binutils 2.30 in
this case).  It failed compiling libgo/runtime/proc.c, creating invalid
assembly:

proc.s: Assembler messages:
proc.s:2092: Error: junk at end of line, first unrecognized character is `*'

        .globl  __emutls_v.*runtime.g

and several more errors.  This is completely unexpected since Solaris
does support TLS.  It turned out that 32-bit TLS detection in
gcc/configure had failed:

configure:25145: checking assembler for thread-local storage support
configure:25158: /usr/gnu/bin/as   --fatal-warnings -o conftest.o conftest.s >&5
conftest.s: Assembler messages:
conftest.s:6: Error: relocated field and relocation type differ in signedness
conftest.s:7: Error: @TLSLDM reloc is not supported with 64-bit output format
conftest.s:7: Error: junk `@tlsldm' after expression

which isn't unexpected given that the bundled gas has been configured
for x86_64-pc-solaris2.11, i.e. 64-bit-default.

This is easily fixed by explicitly passing --32 for the 32-bit case,
matching what is done for the 64-bit test.

Tested on i386-pc-solaris2.11 with 32-bit-default and 64-bit-default gas
as well as with /usr/bin/as, always correctly detecting TLS support.

	* configure.ac <i[34567]86-*-*>: Add --32 to tls_as_opt on Solaris.
	* configure: Regenerate.

The previous URL to an entry in the wayback machine now redirects to a
page saying "SGI.com Tech Archive Resources now retired" so use an older
entry from the archive.

	* doc/xml/faq.xml: Use working link for SGI STL FAQ.
	* doc/html/*: Regenerate.

This fixes two compilation errors preventing bootstrap with Ada
on x86_64-pc-cygwin.

2020-05-04  Mikael Pettersson  <mikpelinux@gmail.com>

	PR bootstrap/94918
	* mingw32.h: Prevent windows.h from including emmintrin.h on Cygw64.
	* s-oscons-tmplt.c (Serial_Port_Descriptor): Use System.Win32.HANDLE
	also on Cygwin.

create_output_operand coerces an output operand to the insn's
predicates, using a suggested rtx location if convenient.
But if that rtx location is actually required rather than
optional, the builder of the insn has to emit a move afterwards.

(We could instead add a new interface that does this automatically,
but that's future work.)

This PR shows that we were failing to emit the move for some of the
vector load internal functions.  I think there are other routines in
internal-fn.c that potentially have the same problem, but this patch is
supposed to be a conservative subset suitable for backporting to GCC 10.

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

gcc/
	PR middle-end/94941
	* internal-fn.c (expand_load_lanes_optab_fn): Emit a move if the
	chosen lhs is different from the gcall lhs.
	(expand_mask_load_optab_fn): Likewise.
	(expand_gather_load_optab_fn): Likewise.

gcc/testsuite/
	PR middle-end/94941
	* gcc.target/aarch64/sve/acle/general/unoptimized_1.c: New test.

	* sv.po: Update.

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

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

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

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

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

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

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

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

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

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

This patch adds the corresponding documentation.


for  gcc/ChangeLog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	* DEV-PHASE: Set to prerelease.

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

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

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

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

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

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

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

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

gcc/cp/ChangeLog:

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

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

gcc/testsuite/ChangeLog:

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

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

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

gcc/cp/ChangeLog:

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

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

gcc/testsuite/ChangeLog:

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

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

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

gcc/cp/ChangeLog:

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

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

gcc/testsuite/ChangeLog:

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

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

gcc/ChangeLog:

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

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

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

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

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

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

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

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

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

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

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

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

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

This is not necessary and weakens the security protection.

gcc/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

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

gcc/d/ChangeLog:

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

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

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

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

libphobos/ChangeLog:

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

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

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

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

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

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

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

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

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

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

gcc/ChangeLog:

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

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

gcc/testsuite/ChangeLog:

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

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

While bootstrapping GCC on S/390 the following warning/error is raised:

gcc/var-tracking.c:10239:34: error: 'pre' may be used uninitialized in this function [-Werror=maybe-uninitialized]
10239 |       VTI (bb)->out.stack_adjust += pre;
      |                                  ^

The lines of interest are:

  HOST_WIDE_INT pre, post = 0;
  // ...
  if (!frame_pointer_needed)
    {
      insn_stack_adjust_offset_pre_post (insn, &pre, &post);
      // ...
    }

  // ...
  adjust_insn (bb, insn);

  if (!frame_pointer_needed && pre)
    VTI (bb)->out.stack_adjust += pre;

Both if statements depend on global variable frame_pointer_needed.  In function
insn_stack_adjust_offset_pre_post local variable pre is initialized.  The
problematic part is the function call between both if statements.  Since
adjust_insn also calls functions which are defined in a different compilation
unit, we are not able to prove that global variable frame_pointer_needed is not
altered by adjust_insn and its siblings.  Thus we must assume that
frame_pointer_needed may be true before the call and false afterwards which
renders the warning true (admitted the location hint is not totally perfect).
By initialising pre we silence the warning.

gcc/ChangeLog:

2020-04-30  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

        * var-tracking.c (vt_initialize): Move variables pre and post
        into inner block and initialize both in order to fix warning
        about uninitialized use.  Remove unnecessary checks for
        frame_pointer_needed.

Ensure that CF does not equal NULL in function output_stack_usage_1
before calling fprintf.  This fixes the following warning/error:

gcc/toplev.c:976:13: error: argument 1 null where non-null expected [-Werror=nonnull]
  976 |     fprintf (cf, "\\n" HOST_WIDE_INT_PRINT_DEC " bytes (%s)",
      |     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  977 |       stack_usage,
      |       ~~~~~~~~~~~~
  978 |       stack_usage_kind_str[stack_usage_kind]);

An example call side where CF is NULL is in function output_stack_usage.

gcc/ChangeLog:

2020-04-30  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

	* toplev.c (output_stack_usage_1): Ensure that first
	argument to fprintf is not null.