Ordinary .cc files have their prerequisite .h files calculated and stored in
build/gcc/cobol/.deps as part of the ordinary build.  But those three oddball
source files only had a few .h files specified, and the ones specified were
incomplete.  Rather than fuss with it, I just made them dependent on all
libgcobol/*.h and gcc/cobol/*.h files.

It was interfering with GDB-COBOL's ability to set a breakpoint at the called routine

libstdc++-v3/ChangeLog:

	* include/debug/safe_local_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS):
	Add parentheses to avoid -Wparentheses warning.

Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g.  std::copy(first, last, first) which
violates the preconditions for the algorithms.

This fix simply returns early if there's nothing to insert. Most callers
already ensure that we don't even call _M_range_insert_aux with an empty
range, but some callers don't. Rather than checking for n == 0 in each
of the callers, this just does the check once and uses __builtin_expect
to treat empty insertions as unlikely.

libstdc++-v3/ChangeLog:

	PR libstdc++/118035
	* include/bits/deque.tcc (_M_range_insert_aux): Return
	immediately if inserting an empty range.
	* testsuite/23_containers/deque/modifiers/insert/118035.cc: New
	test.

PR c/26154 is one of our oldest documentation issues.  The only
discussion of OpenMP support in the GCC manual is buried in the "C
Dialect Options" section, with nothing at all under "Extensions".  The
Fortran manual does have separate sections for OpenMP and OpenACC
extensions so I have copy-edited/adapted that text for similar sections
in the GCC manual, as well as breaking out the OpenMP and OpenACC options
into their own section (they apply to all of C, C++, and Fortran).

I also updated the information about what versions of OpenMP and
OpenACC are supported and removed some redundant text from the Fortran
manual to prevent it from getting out of sync on future updates, and
inserted some cross-references to the new sections elsewhere.

gcc/c-family/ChangeLog
	PR c/26154
	* c.opt.urls: Regenerated.

gcc/ChangeLog
	PR c/26154
	* common.opt.urls: Regenerated.
	* doc/extend.texi (C Extensions): Adjust menu for new sections.
	(Attribute Syntax): Mention OpenMP directives.
	(Pragmas): Mention OpenMP and OpenACC directives.
	(OpenMP): New section.
	(OpenACC): New section.
	* doc/invoke.texi (Invoking GCC): Adjust menu for new section.
	(Option Summary): Move OpenMP and OpenACC options to their own
	category.
	(C Dialect Options): Move documentation for -foffload, -fopenacc,
	-fopenacc-dim, -fopenmp, -fopenmd-simd, and
	-fopenmp-target-simd-clone to...
	(OpenMP and OpenACC Options): ...this new section.  Light
	copy-editing of the option descriptions.

gcc/fortran/ChangeLog:
	PR c/26154
	* gfortran.texi (Standards): Remove redundant info about
	OpenMP/OpenACC standard support.
	(OpenMP): Copy-editing and update version info.
	(OpenACC): Likewise.
	* lang.opt.urls: Regenerated.

The generic expand_vector_piecewise routine supports lowering of
a vector operation to vector operations of smaller size.  When
computing the extract position from the larger vector it uses the
element size in bits of the original result vector to determine
the number of elements in the smaller vector.  That is wrong when
lowering a compare as the vector element size of a bool vector
does not have to agree with that of the compare operand.  The
following simplifies this, fixing the error.

	PR middle-end/118062
	* tree-vect-generic.cc (expand_vector_piecewise): Properly
	compute delta.

This crash started with my r12-7803 but I believe the problem lies
elsewhere.

build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times.  Let's
say we are initializing an array of A.  Then we might end up in
a scenario similar to initlist-eh1.C:

  try
    {
      call A::A in a loop
      // #0
      try
        {
	  call a fn using the array
	}
      finally
	{
	  // #1
	  call A::~A in a loop
	}
    }
  catch
    {
      // #2
      call A::~A in a loop
    }

cleanup_flags makes us emit a statement like

  D.3048 = 2;

at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.

But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value.  Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.

	PR c++/117985

gcc/cp/ChangeLog:

	* init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not
	generating the loop.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/initlist-array23.C: New test.
	* g++.dg/cpp0x/initlist-array24.C: New test.

The patch optimizes code generation for comparisons of the form
X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1).
C1 is a constant that requires li and addi to be loaded,
while ~C1 requires a single lui instruction.
As the values of C1 and C2 are not visible within
the equality expression, a plus pattern is matched instead.

      PR target/114087

gcc/ChangeLog:

	* config/riscv/riscv.md (*lui_constraint<ANYI:mode>_and_to_or): New pattern

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/pr114087-1.c: New test.