Merge branch 'master' into devel/sphinx

11 files changed, 181 insertions, 339 deletions

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c8caf36..826804e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -8551,6 +8551,9 @@ or an array whose component is a @code{union} or a @code{struct}, and it is
 possible for these fields to have a different scalar storage order than the
 enclosing type.
 
+Note that neither pointer nor vector fields are considered scalar fields in
+this context, so the attribute has no effects on these fields.
+
 This attribute is supported only for targets that use a uniform default
 scalar storage order (fortunately, most of them), i.e.@: targets that store
 the scalars either all in big-endian or all in little-endian.
@@ -14706,12 +14709,12 @@ sleep  @var{a}
 @end example
 @end deftypefn
 
-@deftypefn {Built-in Function}  void __builtin_arc_sr (unsigned int @var{auxr}, unsigned int @var{val})
-The first argument, @var{auxv}, is the address of an auxiliary
-register, the second argument, @var{val}, is a compile time constant
-to be written to the register.  Generates:
+@deftypefn {Built-in Function}  void __builtin_arc_sr (unsigned int @var{val}, unsigned int @var{auxr})
+The first argument, @var{val}, is a compile time constant to be
+written to the register, the second argument, @var{auxr}, is the
+address of an auxiliary register.  Generates:
 @example
-sr  @var{auxr}, [@var{val}]
+sr  @var{val}, [@var{auxr}]
 @end example
 @end deftypefn
 
diff --git a/gcc/doc/frontends.texi b/gcc/doc/frontends.texi
index 78f579f..7ff691b 100644
--- a/gcc/doc/frontends.texi
+++ b/gcc/doc/frontends.texi
@@ -17,7 +17,7 @@
 GCC stands for ``GNU Compiler Collection''.  GCC is an integrated
 distribution of compilers for several major programming languages.  These
 languages currently include C, C++, Objective-C, Objective-C++,
-Fortran, Ada, D, Go, and BRIG (HSAIL).
+Fortran, Ada, D, and Go.
 
 The abbreviation @dfn{GCC} has multiple meanings in common use.  The
 current official meaning is ``GNU Compiler Collection'', which refers
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 6966308..e0a07c3 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2239,6 +2239,14 @@ specifying paths @var{path1}, @dots{}, @var{pathN}.
     --enable-offload-targets=x86_64-intelmicemul-linux-gnu=/path/to/x86_64/compiler,nvptx-none
 @end smallexample
 
+@item --enable-offload-defaulted
+
+Tell GCC that configured but not installed offload compilers and libgomp
+plugins are silently ignored.  Useful for distribution compilers where
+those are in separate optional packages and where the presence or absence
+of those optional packages should determine the actual supported offloading
+target set rather than the GCC configure-time selection.
+
 @item --with-hsa-runtime=@var{pathname}
 @itemx --with-hsa-runtime-include=@var{pathname}
 @itemx --with-hsa-runtime-lib=@var{pathname}
@@ -2987,10 +2995,8 @@ separately.
 
 Second, you must have the testing tools installed.  This includes
 @uref{http://www.gnu.org/software/dejagnu/,,DejaGnu}, Tcl, and Expect;
-the DejaGnu site has links to these. For running the BRIG frontend
-tests, a tool to assemble the binary BRIGs from HSAIL text,
-@uref{https://github.com/HSAFoundation/HSAIL-Tools/,,HSAILasm} must
-be installed.  Some optional tests also require Python3 and pytest module.
+the DejaGnu site has links to these.
+Some optional tests also require Python3 and pytest module.
 
 If the directories where @command{runtest} and @command{expect} were
 installed are not in the @env{PATH}, you may need to set the following
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 71faa9b..852617d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -364,7 +364,9 @@ Objective-C and Objective-C++ Dialects}.
 -Wmissing-include-dirs  -Wmissing-noreturn  -Wno-missing-profile @gol
 -Wno-multichar  -Wmultistatement-macros  -Wnonnull  -Wnonnull-compare @gol
 -Wnormalized=@r{[}none@r{|}id@r{|}nfc@r{|}nfkc@r{]} @gol
--Wnull-dereference  -Wno-odr  -Wopenmp-simd  @gol
+-Wnull-dereference  -Wno-odr  @gol
+-Wopenacc-parallelism  @gol
+-Wopenmp-simd  @gol
 -Wno-overflow  -Woverlength-strings  -Wno-override-init-side-effects @gol
 -Wpacked  -Wno-packed-bitfield-compat  -Wpacked-not-aligned  -Wpadded @gol
 -Wparentheses  -Wno-pedantic-ms-format @gol
@@ -1536,9 +1538,6 @@ traditional preprocessor).
 @item @var{file}.go
 Go source code.
 
-@item @var{file}.brig
-BRIG files (binary representation of HSAIL).
-
 @item @var{file}.d
 D source code.
 
@@ -1594,7 +1593,6 @@ ada
 d
 f77  f77-cpp-input f95  f95-cpp-input
 go
-brig
 @end smallexample
 
 @item -x none
@@ -8749,6 +8747,12 @@ Do not warn about compile-time overflow in constant expressions.
 Warn about One Definition Rule violations during link-time optimization.
 Enabled by default.
 
+@item -Wopenacc-parallelism
+@opindex Wopenacc-parallelism
+@opindex Wno-openacc-parallelism
+@cindex OpenACC accelerator programming
+Warn about potentially suboptimal choices related to OpenACC parallelism.
+
 @item -Wopenmp-simd
 @opindex Wopenmp-simd
 @opindex Wno-openmp-simd
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index d166a0d..0e65b3a 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -7071,7 +7071,7 @@ such as
   [(set (pc)
         (if_then_else (match_operator
                          0 "comparison_operator"
-                         [(cc0) (const_int 0)])
+                         [(reg:CC CC_REG) (const_int 0)])
                       (return)
                       (pc)))]
   "@var{condition}"
@@ -7989,15 +7989,8 @@ works better when different sets of comparison operators are supported
 by different kinds of conditional branches (e.g.@: integer vs.@:
 floating-point), or by conditional branches with respect to conditional stores.
 
-Two separate insns are always used if the machine description represents
-a condition code register using the legacy RTL expression @code{(cc0)},
-and on most machines that use a separate condition code register
-(@pxref{Condition Code}).  For machines that use @code{(cc0)}, in
-fact, the set and use of the condition code must be separate and
-adjacent@footnote{@code{note} insns can separate them, though.}, thus
-allowing flags in @code{cc_status} to be used (@pxref{Condition Code}) and
-so that the comparison and branch insns could be located from each other
-by using the functions @code{prev_cc0_setter} and @code{next_cc0_user}.
+Two separate insns are always used on most machines that use a separate
+condition code register (@pxref{Condition Code}).
 
 Even in this case having a single entry point for conditional branches
 is advantageous, because it handles equally well the case where a single
@@ -8191,7 +8184,7 @@ the operations as far as possible.  For instance,
 @cindex @code{compare}, canonicalization of
 @item
 For the @code{compare} operator, a constant is always the second operand
-if the first argument is a condition code register or @code{(cc0)}.
+if the first argument is a condition code register.
 
 @item
 For instructions that inherently set a condition code register, the
@@ -9330,8 +9323,7 @@ In addition to describing the instruction supported by the target machine,
 the @file{md} file also defines a group of @dfn{attributes} and a set of
 values for each.  Every generated insn is assigned a value for each attribute.
 One possible attribute would be the effect that the insn has on the machine's
-condition code.  This attribute can then be used by @code{NOTICE_UPDATE_CC}
-to track the condition codes.
+condition code.
 
 @menu
 * Defining Attributes:: Specifying attributes and their values.
diff --git a/gcc/doc/options.texi b/gcc/doc/options.texi
index 2057629e..ce5e2e4 100644
--- a/gcc/doc/options.texi
+++ b/gcc/doc/options.texi
@@ -223,8 +223,8 @@ propagate through the @code{Negative} property of the option to be
 turned off.  The driver will prune options, removing those that are
 turned off by some later option.  This pruning is not done for options
 with @code{Joined} or @code{JoinedOrMissing} properties, unless the
-options have either @code{RejectNegative} property or the @code{Negative}
-property mentions an option other than itself.
+options have both the @code{RejectNegative} property and the @code{Negative}
+property mentions itself.
 
 As a consequence, if you have a group of mutually-exclusive
 options, their @code{Negative} properties should form a circular chain.
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index edbc60f..5af7113 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -1271,8 +1271,7 @@ accumulator.  The default format is ``64.64''.
 ``Condition Code'' mode represents the value of a condition code, which
 is a machine-specific set of bits used to represent the result of a
 comparison operation.  Other machine-specific modes may also be used for
-the condition code.  These modes are not used on machines that use
-@code{cc0} (@pxref{Condition Code}).
+the condition code.  (@pxref{Condition Code}).
 
 @findex BLKmode
 @item BLKmode
@@ -2324,60 +2323,17 @@ the reload pass.
 @code{scratch} is usually present inside a @code{clobber} operation
 (@pxref{Side Effects}).
 
-@findex cc0
-@cindex condition code register
-@item (cc0)
-This refers to the machine's condition code register.  It has no
-operands and may not have a machine mode.  There are two ways to use it:
-
-@itemize @bullet
-@item
-To stand for a complete set of condition code flags.  This is best on
-most machines, where each comparison sets the entire series of flags.
-
-With this technique, @code{(cc0)} may be validly used in only two
-contexts: as the destination of an assignment (in test and compare
-instructions) and in comparison operators comparing against zero
-(@code{const_int} with value zero; that is to say, @code{const0_rtx}).
-
-@item
-To stand for a single flag that is the result of a single condition.
-This is useful on machines that have only a single flag bit, and in
-which comparison instructions must specify the condition to test.
-
-With this technique, @code{(cc0)} may be validly used in only two
-contexts: as the destination of an assignment (in test and compare
-instructions) where the source is a comparison operator, and as the
-first operand of @code{if_then_else} (in a conditional branch).
-@end itemize
-
-@findex cc0_rtx
-There is only one expression object of code @code{cc0}; it is the
-value of the variable @code{cc0_rtx}.  Any attempt to create an
-expression of code @code{cc0} will return @code{cc0_rtx}.
-
-Instructions can set the condition code implicitly.  On many machines,
-nearly all instructions set the condition code based on the value that
-they compute or store.  It is not necessary to record these actions
-explicitly in the RTL because the machine description includes a
-prescription for recognizing the instructions that do so (by means of
-the macro @code{NOTICE_UPDATE_CC}).  @xref{Condition Code}.  Only
-instructions whose sole purpose is to set the condition code, and
-instructions that use the condition code, need mention @code{(cc0)}.
-
 On some machines, the condition code register is given a register number
-and a @code{reg} is used instead of @code{(cc0)}.  This is usually the
-preferable approach if only a small subset of instructions modify the
-condition code.  Other machines store condition codes in general
+and a @code{reg} is used.
+Other machines store condition codes in general
 registers; in such cases a pseudo register should be used.
 
 Some machines, such as the SPARC and RS/6000, have two sets of
 arithmetic instructions, one that sets and one that does not set the
 condition code.  This is best handled by normally generating the
 instruction that does not set the condition code, and making a pattern
-that both performs the arithmetic and sets the condition code register
-(which would not be @code{(cc0)} in this case).  For examples, search
-for @samp{addcc} and @samp{andcc} in @file{sparc.md}.
+that both performs the arithmetic and sets the condition code register.
+For examples, search for @samp{addcc} and @samp{andcc} in @file{sparc.md}.
 
 @findex pc
 @item (pc)
@@ -2495,14 +2451,13 @@ Of course, machines cannot really subtract with infinite precision.
 However, they can pretend to do so when only the sign of the result will
 be used, which is the case when the result is stored in the condition
 code.  And that is the @emph{only} way this kind of expression may
-validly be used: as a value to be stored in the condition codes, either
-@code{(cc0)} or a register.  @xref{Comparisons}.
+validly be used: as a value to be stored in the condition codes, in a
+register.  @xref{Comparisons}.
 
 The mode @var{m} is not related to the modes of @var{x} and @var{y}, but
-instead is the mode of the condition code value.  If @code{(cc0)} is
-used, it is @code{VOIDmode}.  Otherwise it is some mode in class
+instead is the mode of the condition code value.  It is some mode in class
 @code{MODE_CC}, often @code{CCmode}.  @xref{Condition Code}.  If @var{m}
-is @code{VOIDmode} or @code{CCmode}, the operation returns sufficient
+is @code{CCmode}, the operation returns sufficient
 information (in an unspecified format) so that any comparison operator
 can be applied to the result of the @code{COMPARE} operation.  For other
 modes in class @code{MODE_CC}, the operation only returns a subset of
@@ -2797,26 +2752,17 @@ of the data being compared.  If the comparison operation is being tested
 @code{VOIDmode}.
 
 @cindex condition codes
-There are two ways that comparison operations may be used.  The
-comparison operators may be used to compare the condition codes
-@code{(cc0)} against zero, as in @code{(eq (cc0) (const_int 0))}.  Such
-a construct actually refers to the result of the preceding instruction
-in which the condition codes were set.  The instruction setting the
-condition code must be adjacent to the instruction using the condition
-code; only @code{note} insns may separate them.
-
-Alternatively, a comparison operation may directly compare two data
+A comparison operation compares two data
 objects.  The mode of the comparison is determined by the operands; they
 must both be valid for a common machine mode.  A comparison with both
 operands constant would be invalid as the machine mode could not be
 deduced from it, but such a comparison should never exist in RTL due to
 constant folding.
 
-In the example above, if @code{(cc0)} were last set to
-@code{(compare @var{x} @var{y})}, the comparison operation is
-identical to @code{(eq @var{x} @var{y})}.  Usually only one style
+Usually only one style
 of comparisons is supported on a particular machine, but the combine
-pass will try to merge the operations to produce the @code{eq} shown
+pass will try to merge operations to produce code like
+@code{(eq @var{x} @var{y})},
 in case it exists in the context of the particular insn involved.
 
 Inequality comparisons come in two flavors, signed and unsigned.  Thus,
@@ -3168,7 +3114,7 @@ Represents the action of storing the value of @var{x} into the place
 represented by @var{lval}.  @var{lval} must be an expression
 representing a place that can be stored in: @code{reg} (or @code{subreg},
 @code{strict_low_part} or @code{zero_extract}), @code{mem}, @code{pc},
-@code{parallel}, or @code{cc0}.
+or @code{parallel}.
 
 If @var{lval} is a @code{reg}, @code{subreg} or @code{mem}, it has a
 machine mode; then @var{x} must be valid for that mode.
@@ -3191,13 +3137,6 @@ the bit-field (a memory or register reference) specified by the
 bit-field is not changed.  Note that @code{sign_extract} cannot
 appear in @var{lval}.
 
-If @var{lval} is @code{(cc0)}, it has no machine mode, and @var{x} may
-be either a @code{compare} expression or a value that may have any mode.
-The latter case represents a ``test'' instruction.  The expression
-@code{(set (cc0) (reg:@var{m} @var{n}))} is equivalent to
-@code{(set (cc0) (compare (reg:@var{m} @var{n}) (const_int 0)))}.
-Use the former expression to save space during the compilation.
-
 If @var{lval} is a @code{parallel}, it is used to represent the case of
 a function returning a structure in multiple registers.  Each element
 of the @code{parallel} is an @code{expr_list} whose first operand is a
@@ -3219,7 +3158,7 @@ does not jump) and the other of the two must be a @code{label_ref}
 @code{mem}; these unusual patterns are used to represent jumps through
 branch tables.
 
-If @var{lval} is neither @code{(cc0)} nor @code{(pc)}, the mode of
+If @var{lval} is not @code{(pc)}, the mode of
 @var{lval} must not be @code{VOIDmode} and the mode of @var{x} must be
 valid for the mode of @var{lval}.
 
@@ -3402,9 +3341,9 @@ For example, people sometimes attempt to represent a jump-if-zero
 instruction this way:
 
 @smallexample
-(parallel [(set (cc0) (reg:SI 34))
+(parallel [(set (reg:CC CC_REG) (reg:SI 34))
            (set (pc) (if_then_else
-                        (eq (cc0) (const_int 0))
+                        (eq (reg:CC CC_REG) (const_int 0))
                         (label_ref @dots{})
                         (pc)))])
 @end smallexample
@@ -3421,8 +3360,6 @@ whose elements are the operands needed to output the resulting
 assembler code---often @code{reg}, @code{mem} or constant expressions.
 This would not be well-formed RTL at any other stage in compilation,
 but it is OK then because no further optimization remains to be done.
-However, the definition of the macro @code{NOTICE_UPDATE_CC}, if
-any, must deal with such insns if you define any peephole optimizations.
 
 @findex cond_exec
 @item (cond_exec [@var{cond} @var{expr}])
@@ -4101,14 +4038,6 @@ In the debugging output, this field is printed as a number followed by
 a symbolic representation that locates the pattern in the @file{md}
 file as some small positive or negative offset from a named pattern.
 
-@findex LOG_LINKS
-@item LOG_LINKS (@var{i})
-A list (chain of @code{insn_list} expressions) giving information about
-dependencies between instructions within a basic block.  Neither a jump
-nor a label may come between the related insns.  These are only used by
-the schedulers and by combine.  This is a deprecated data structure.
-Def-use and use-def chains are now preferred.
-
 @findex REG_NOTES
 @item REG_NOTES (@var{i})
 A list (chain of @code{expr_list}, @code{insn_list} and @code{int_list}
@@ -4116,23 +4045,9 @@ expressions) giving miscellaneous information about the insn.  It is often
 information pertaining to the registers used in this insn.
 @end table
 
-The @code{LOG_LINKS} field of an insn is a chain of @code{insn_list}
-expressions.  Each of these has two operands: the first is an insn,
-and the second is another @code{insn_list} expression (the next one in
-the chain).  The last @code{insn_list} in the chain has a null pointer
-as second operand.  The significant thing about the chain is which
-insns appear in it (as first operands of @code{insn_list}
-expressions).  Their order is not significant.
-
-This list is originally set up by the flow analysis pass; it is a null
-pointer until then.  Flow only adds links for those data dependencies
-which can be used for instruction combination.  For each insn, the flow
-analysis pass adds a link to insns which store into registers values
-that are used for the first time in this insn.
-
-The @code{REG_NOTES} field of an insn is a chain similar to the
-@code{LOG_LINKS} field but it includes @code{expr_list} and @code{int_list}
-expressions in addition to @code{insn_list} expressions.  There are several
+The @code{REG_NOTES} field of an insn is a chain that includes
+@code{expr_list} and @code{int_list} expressions as well as @code{insn_list}
+expressions.  There are several
 kinds of register notes, which are distinguished by the machine mode, which
 in a register note is really understood as being an @code{enum reg_note}.
 The first operand @var{op} of the note is data whose meaning depends on
@@ -4147,8 +4062,7 @@ register note.  Its counterpart, the macro @code{PUT_REG_NOTE_KIND
 
 Register notes are of three classes: They may say something about an
 input to an insn, they may say something about an output of an insn, or
-they may create a linkage between two insns.  There are also a set
-of values that are only used in @code{LOG_LINKS}.
+they may create a linkage between two insns.
 
 These register notes annotate inputs to an insn:
 
@@ -4290,26 +4204,6 @@ insn has one of a pair of notes that points to a second insn, which has
 the inverse note pointing back to the first insn.
 
 @table @code
-@findex REG_CC_SETTER
-@findex REG_CC_USER
-@item REG_CC_SETTER
-@itemx REG_CC_USER
-On machines that use @code{cc0}, the insns which set and use @code{cc0}
-set and use @code{cc0} are adjacent.  However, when branch delay slot
-filling is done, this may no longer be true.  In this case a
-@code{REG_CC_USER} note will be placed on the insn setting @code{cc0} to
-point to the insn using @code{cc0} and a @code{REG_CC_SETTER} note will
-be placed on the insn using @code{cc0} to point to the insn setting
-@code{cc0}.
-@end table
-
-These values are only used in the @code{LOG_LINKS} field, and indicate
-the type of dependency that each link represents.  Links which indicate
-a data dependence (a read after write dependence) do not use any code,
-they simply have mode @code{VOIDmode}, and are printed without any
-descriptive text.
-
-@table @code
 @findex REG_DEP_TRUE
 @item REG_DEP_TRUE
 This indicates a true dependence (a read after write dependence).
@@ -5272,10 +5166,6 @@ are shared.
 @item
 There is only one @code{pc} expression.
 
-@cindex @code{cc0}, RTL sharing
-@item
-There is only one @code{cc0} expression.
-
 @cindex @code{const_double}, RTL sharing
 @item
 There is only one @code{const_double} expression with value 0 for
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index b000124..3a1d653 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1301,6 +1301,8 @@ A selector is:
 @item one or more target triplets, possibly including wildcard characters;
 use @samp{*-*-*} to match any target
 @item a single effective-target keyword (@pxref{Effective-Target Keywords})
+@item a list of compiler options that should be included or excluded
+(as described in more detail below)
 @item a logical expression
 @end itemize
 
@@ -1313,14 +1315,96 @@ test to fail for targets that match @var{selector2}.
 
 A selector expression appears within curly braces and uses a single
 logical operator: one of @samp{!}, @samp{&&}, or @samp{||}.  An
-operand is another selector expression, an effective-target keyword,
-a single target triplet, or a list of target triplets within quotes or
-curly braces.  For example:
+operand is one of the following:
+
+@itemize @bullet
+@item
+another selector expression, in curly braces
+
+@item
+an effective-target keyword, such as @code{lp64}
+
+@item
+a single target triplet
+
+@item
+a list of target triplets within quotes or curly braces
+
+@item
+one of the following:
+
+@table @samp
+@item @{ any-opts @var{opt1} @dots{} @var{optn} @}
+Each of @var{opt1} to @var{optn} is a space-separated list of option globs.
+The selector expression evaluates to true if, for one of these strings,
+every glob in the string matches an option that was passed to the compiler.
+For example:
+
+@smallexample
+@{ any-opts "-O3 -flto" "-O[2g]" @}
+@end smallexample
+
+is true if any of the following are true:
+
+@itemize @bullet
+@item
+@option{-O2} was passed to the compiler
+
+@item
+@option{-Og} was passed to the compiler
+
+@item
+both @option{-O3} and @option{-flto} were passed to the compiler
+@end itemize
+
+This kind of selector can only be used within @code{dg-final} directives.
+Use @code{dg-skip-if}, @code{dg-xfail-if} or @code{dg-xfail-run-if} to
+skip whole tests based on options, or to mark them as expected to fail
+with certain options.
+
+@item @{ no-opts @var{opt1} @dots{} @var{optn} @}
+As for @code{any-opts} above, each of @var{opt1} to @var{optn} is a
+space-separated list of option globs.  The selector expression
+evaluates to true if, for all of these strings, there is at least
+one glob that does not match an option that was passed to the compiler.
+It is shorthand for:
+
+@smallexample
+@{ ! @{ any-opts @var{opt1} @dots{} @var{optn} @} @}
+@end smallexample
+
+For example:
+
+@smallexample
+@{ no-opts "-O3 -flto" "-O[2g]" @}
+@end smallexample
+
+is true if all of the following are true:
+
+@itemize @bullet
+@item
+@option{-O2} was not passed to the compiler
+
+@item
+@option{-Og} was not passed to the compiler
+
+@item
+at least one of @option{-O3} or @option{-flto} was not passed to the compiler
+@end itemize
+
+Like @code{any-opts}, this kind of selector can only be used within
+@code{dg-final} directives.
+
+@end table
+@end itemize
+
+Here are some examples of full target selectors:
 
 @smallexample
 @{ target @{ ! "hppa*-*-* ia64*-*-*" @} @}
 @{ target @{ powerpc*-*-* && lp64 @} @}
 @{ xfail @{ lp64 || vect_no_align @} @}
+@{ xfail @{ aarch64*-*-* && @{ any-opts "-O2" @} @} @}
 @end smallexample
 
 @node Effective-Target Keywords
@@ -2012,6 +2096,9 @@ div instruction.
 ARM target supports ARMv8-M Security Extensions, enabled by the @code{-mcmse}
 option.
 
+@item arm_cmse_hw
+Test system supports executing CMSE instructions.
+
 @item arm_coproc1_ok
 @anchor{arm_coproc1_ok}
 ARM target supports the following coprocessor instructions: @code{CDP},
diff --git a/gcc/doc/standards.texi b/gcc/doc/standards.texi
index 0f88333..128b1c6 100644
--- a/gcc/doc/standards.texi
+++ b/gcc/doc/standards.texi
@@ -320,14 +320,6 @@ available online, see @uref{http://gcc.gnu.org/readings.html}
 As of the GCC 4.7.1 release, GCC supports the Go 1 language standard,
 described at @uref{https://golang.org/doc/go1}.
 
-@section HSA Intermediate Language (HSAIL)
-
-GCC can compile the binary representation (BRIG) of the HSAIL text format as
-described in HSA Programmer's Reference Manual version 1.0.1. This
-capability is typically utilized to implement the HSA runtime API's HSAIL 
-finalization extension for a gcc supported processor. HSA standards are
-freely available at @uref{http://www.hsafoundation.com/standards/}.
-
 @section D language
 
 GCC supports the D 2.0 programming language.  The D language itself is
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 823f85b..85ea939 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -5880,6 +5880,15 @@ This hook returns true if @var{x} is a legitimate constant for a
 The default definition returns true.
 @end deftypefn
 
+@deftypefn {Target Hook} bool TARGET_PRECOMPUTE_TLS_P (machine_mode @var{mode}, rtx @var{x})
+This hook returns true if @var{x} is a TLS operand on the target
+machine that should be pre-computed when used as the argument in a call.
+You can assume that @var{x} satisfies @code{CONSTANT_P}, so you need not 
+check this.
+
+The default definition returns false.
+@end deftypefn
+
 @deftypefn {Target Hook} rtx TARGET_DELEGITIMIZE_ADDRESS (rtx @var{x})
 This hook is used to undo the possibly obfuscating effects of the
 @code{LEGITIMIZE_ADDRESS} and @code{LEGITIMIZE_RELOAD_ADDRESS} target
@@ -6111,8 +6120,8 @@ type @code{internal_fn}) should be considered expensive when the mask is
 all zeros.  GCC can then try to branch around the instruction instead.
 @end deftypefn
 
-@deftypefn {Target Hook} {void *} TARGET_VECTORIZE_INIT_COST (class loop *@var{loop_info})
-This hook should initialize target-specific data structures in preparation for modeling the costs of vectorizing a loop or basic block.  The default allocates three unsigned integers for accumulating costs for the prologue, body, and epilogue of the loop or basic block.  If @var{loop_info} is non-NULL, it identifies the loop being vectorized; otherwise a single block is being vectorized.
+@deftypefn {Target Hook} {void *} TARGET_VECTORIZE_INIT_COST (class loop *@var{loop_info}, bool @var{costing_for_scalar})
+This hook should initialize target-specific data structures in preparation for modeling the costs of vectorizing a loop or basic block.  The default allocates three unsigned integers for accumulating costs for the prologue, body, and epilogue of the loop or basic block.  If @var{loop_info} is non-NULL, it identifies the loop being vectorized; otherwise a single block is being vectorized.  If @var{costing_for_scalar} is true, it indicates the current cost model is for the scalar version of a loop or block; otherwise it is for the vector version.
 @end deftypefn
 
 @deftypefn {Target Hook} unsigned TARGET_VECTORIZE_ADD_STMT_COST (class vec_info *@var{}, void *@var{data}, int @var{count}, enum vect_cost_for_stmt @var{kind}, class _stmt_vec_info *@var{stmt_info}, tree @var{vectype}, int @var{misalign}, enum vect_cost_model_location @var{where})
@@ -6301,21 +6310,16 @@ or target-specific sections.
 @section Condition Code Status
 @cindex condition code status
 
-The macros in this section can be split in two families, according to the
-two ways of representing condition codes in GCC.
-
-The first representation is the so called @code{(cc0)} representation
-(@pxref{Jump Patterns}), where all instructions can have an implicit
-clobber of the condition codes.  The second is the condition code
-register representation, which provides better schedulability for
+Condition codes in GCC are represented as registers,
+which provides better schedulability for
 architectures that do have a condition code register, but on which
 most instructions do not affect it.  The latter category includes
 most RISC machines.
 
-The implicit clobbering poses a strong restriction on the placement of
+Implicit clobbering would pose a strong restriction on the placement of
 the definition and use of the condition code.  In the past the definition
 and use were always adjacent.  However, recent changes to support trapping
-arithmatic may result in the definition and user being in different blocks.
+arithmetic may result in the definition and user being in different blocks.
 Thus, there may be a @code{NOTE_INSN_BASIC_BLOCK} between them.  Additionally,
 the definition may be the source of exception handling edges.
 
@@ -6326,8 +6330,7 @@ three instructions earlier than the conditional branch.  The instruction
 scheduler cannot perform this optimization if it is not permitted to
 separate the definition and use of the condition code register.
 
-For this reason, it is possible and suggested to use a register to
-represent the condition code for new ports.  If there is a specific
+If there is a specific
 condition code register in the machine, use a hard register.  If the
 condition code or comparison result can be placed in any general register,
 or if there are multiple condition registers, use a pseudo register.
@@ -6339,78 +6342,9 @@ specified already in the compare instruction.  In this case, you are not
 interested in most macros in this section.
 
 @menu
-* CC0 Condition Codes::      Old style representation of condition codes.
 * MODE_CC Condition Codes::  Modern representation of condition codes.
 @end menu
 
-@node CC0 Condition Codes
-@subsection Representation of condition codes using @code{(cc0)}
-@findex cc0
-
-@findex cc_status
-The file @file{conditions.h} defines a variable @code{cc_status} to
-describe how the condition code was computed (in case the interpretation of
-the condition code depends on the instruction that it was set by).  This
-variable contains the RTL expressions on which the condition code is
-currently based, and several standard flags.
-
-Sometimes additional machine-specific flags must be defined in the machine
-description header file.  It can also add additional machine-specific
-information by defining @code{CC_STATUS_MDEP}.
-
-@defmac CC_STATUS_MDEP
-C code for a data type which is used for declaring the @code{mdep}
-component of @code{cc_status}.  It defaults to @code{int}.
-
-This macro is not used on machines that do not use @code{cc0}.
-@end defmac
-
-@defmac CC_STATUS_MDEP_INIT
-A C expression to initialize the @code{mdep} field to ``empty''.
-The default definition does nothing, since most machines don't use
-the field anyway.  If you want to use the field, you should probably
-define this macro to initialize it.
-
-This macro is not used on machines that do not use @code{cc0}.
-@end defmac
-
-@defmac NOTICE_UPDATE_CC (@var{exp}, @var{insn})
-A C compound statement to set the components of @code{cc_status}
-appropriately for an insn @var{insn} whose body is @var{exp}.  It is
-this macro's responsibility to recognize insns that set the condition
-code as a byproduct of other activity as well as those that explicitly
-set @code{(cc0)}.
-
-This macro is not used on machines that do not use @code{cc0}.
-
-If there are insns that do not set the condition code but do alter
-other machine registers, this macro must check to see whether they
-invalidate the expressions that the condition code is recorded as
-reflecting.  For example, on the 68000, insns that store in address
-registers do not set the condition code, which means that usually
-@code{NOTICE_UPDATE_CC} can leave @code{cc_status} unaltered for such
-insns.  But suppose that the previous insn set the condition code
-based on location @samp{a4@@(102)} and the current insn stores a new
-value in @samp{a4}.  Although the condition code is not changed by
-this, it will no longer be true that it reflects the contents of
-@samp{a4@@(102)}.  Therefore, @code{NOTICE_UPDATE_CC} must alter
-@code{cc_status} in this case to say that nothing is known about the
-condition code value.
-
-The definition of @code{NOTICE_UPDATE_CC} must be prepared to deal
-with the results of peephole optimization: insns whose patterns are
-@code{parallel} RTXs containing various @code{reg}, @code{mem} or
-constants which are just the operands.  The RTL structure of these
-insns is not sufficient to indicate what the insns actually do.  What
-@code{NOTICE_UPDATE_CC} should do when it sees one is just to run
-@code{CC_STATUS_INIT}.
-
-A possible definition of @code{NOTICE_UPDATE_CC} is to call a function
-that looks at an attribute (@pxref{Insn Attributes}) named, for example,
-@samp{cc}.  This avoids having detailed information about patterns in
-two places, the @file{md} file and in @code{NOTICE_UPDATE_CC}.
-@end defmac
-
 @node MODE_CC Condition Codes
 @subsection Representation of condition codes using registers
 @findex CCmode
@@ -6525,7 +6459,7 @@ like:
 @end defmac
 
 @deftypefn {Target Hook} bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *@var{p1}, unsigned int *@var{p2})
-On targets which do not use @code{(cc0)}, and which use a hard
+On targets which use a hard
 register rather than a pseudo-register to hold condition codes, the
 regular CSE passes are often not able to identify cases in which the
 hard register is set to a common value.  Use this hook to enable a
@@ -6758,6 +6692,13 @@ in code size, for example where the number of insns emitted to perform a
 move would be greater than that of a library call.
 @end deftypefn
 
+@deftypefn {Target Hook} bool TARGET_OVERLAP_OP_BY_PIECES_P (void)
+This target hook should return true if when the @code{by_pieces}
+infrastructure is used, an offset adjusted unaligned memory operation
+in the smallest integer mode for the last piece operation of a memory
+region can be generated to avoid doing more than one smaller operations.
+@end deftypefn
+
 @deftypefn {Target Hook} int TARGET_COMPARE_BY_PIECES_BRANCH_RATIO (machine_mode @var{mode})
 When expanding a block comparison in MODE, gcc can try to reduce the
 number of branches at the expense of more memory operations.  This hook
@@ -11562,8 +11503,7 @@ for cross-profiling.
 
 A C expression for the maximum number of instructions to execute via
 conditional execution instructions instead of a branch.  A value of
-@code{BRANCH_COST}+1 is the default if the machine does not use cc0, and
-1 if it does use cc0.
+@code{BRANCH_COST}+1 is the default.
 @end defmac
 
 @defmac IFCVT_MODIFY_TESTS (@var{ce_info}, @var{true_expr}, @var{false_expr})
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 2321a5f..d8e3de1 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4147,6 +4147,8 @@ address;  but often a machine-dependent strategy can generate better code.
 
 @hook TARGET_LEGITIMATE_CONSTANT_P
 
+@hook TARGET_PRECOMPUTE_TLS_P
+
 @hook TARGET_DELEGITIMIZE_ADDRESS
 
 @hook TARGET_CONST_NOT_OK_FOR_DEBUG_P
@@ -4266,21 +4268,16 @@ or @code{TARGET_MAX_ANCHOR_OFFSET} is set to a nonzero value.
 @section Condition Code Status
 @cindex condition code status
 
-The macros in this section can be split in two families, according to the
-two ways of representing condition codes in GCC.
-
-The first representation is the so called @code{(cc0)} representation
-(@pxref{Jump Patterns}), where all instructions can have an implicit
-clobber of the condition codes.  The second is the condition code
-register representation, which provides better schedulability for
+Condition codes in GCC are represented as registers,
+which provides better schedulability for
 architectures that do have a condition code register, but on which
 most instructions do not affect it.  The latter category includes
 most RISC machines.
 
-The implicit clobbering poses a strong restriction on the placement of
+Implicit clobbering would pose a strong restriction on the placement of
 the definition and use of the condition code.  In the past the definition
 and use were always adjacent.  However, recent changes to support trapping
-arithmatic may result in the definition and user being in different blocks.
+arithmetic may result in the definition and user being in different blocks.
 Thus, there may be a @code{NOTE_INSN_BASIC_BLOCK} between them.  Additionally,
 the definition may be the source of exception handling edges.
 
@@ -4291,8 +4288,7 @@ three instructions earlier than the conditional branch.  The instruction
 scheduler cannot perform this optimization if it is not permitted to
 separate the definition and use of the condition code register.
 
-For this reason, it is possible and suggested to use a register to
-represent the condition code for new ports.  If there is a specific
+If there is a specific
 condition code register in the machine, use a hard register.  If the
 condition code or comparison result can be placed in any general register,
 or if there are multiple condition registers, use a pseudo register.
@@ -4304,78 +4300,9 @@ specified already in the compare instruction.  In this case, you are not
 interested in most macros in this section.
 
 @menu
-* CC0 Condition Codes::      Old style representation of condition codes.
 * MODE_CC Condition Codes::  Modern representation of condition codes.
 @end menu
 
-@node CC0 Condition Codes
-@subsection Representation of condition codes using @code{(cc0)}
-@findex cc0
-
-@findex cc_status
-The file @file{conditions.h} defines a variable @code{cc_status} to
-describe how the condition code was computed (in case the interpretation of
-the condition code depends on the instruction that it was set by).  This
-variable contains the RTL expressions on which the condition code is
-currently based, and several standard flags.
-
-Sometimes additional machine-specific flags must be defined in the machine
-description header file.  It can also add additional machine-specific
-information by defining @code{CC_STATUS_MDEP}.
-
-@defmac CC_STATUS_MDEP
-C code for a data type which is used for declaring the @code{mdep}
-component of @code{cc_status}.  It defaults to @code{int}.
-
-This macro is not used on machines that do not use @code{cc0}.
-@end defmac
-
-@defmac CC_STATUS_MDEP_INIT
-A C expression to initialize the @code{mdep} field to ``empty''.
-The default definition does nothing, since most machines don't use
-the field anyway.  If you want to use the field, you should probably
-define this macro to initialize it.
-
-This macro is not used on machines that do not use @code{cc0}.
-@end defmac
-
-@defmac NOTICE_UPDATE_CC (@var{exp}, @var{insn})
-A C compound statement to set the components of @code{cc_status}
-appropriately for an insn @var{insn} whose body is @var{exp}.  It is
-this macro's responsibility to recognize insns that set the condition
-code as a byproduct of other activity as well as those that explicitly
-set @code{(cc0)}.
-
-This macro is not used on machines that do not use @code{cc0}.
-
-If there are insns that do not set the condition code but do alter
-other machine registers, this macro must check to see whether they
-invalidate the expressions that the condition code is recorded as
-reflecting.  For example, on the 68000, insns that store in address
-registers do not set the condition code, which means that usually
-@code{NOTICE_UPDATE_CC} can leave @code{cc_status} unaltered for such
-insns.  But suppose that the previous insn set the condition code
-based on location @samp{a4@@(102)} and the current insn stores a new
-value in @samp{a4}.  Although the condition code is not changed by
-this, it will no longer be true that it reflects the contents of
-@samp{a4@@(102)}.  Therefore, @code{NOTICE_UPDATE_CC} must alter
-@code{cc_status} in this case to say that nothing is known about the
-condition code value.
-
-The definition of @code{NOTICE_UPDATE_CC} must be prepared to deal
-with the results of peephole optimization: insns whose patterns are
-@code{parallel} RTXs containing various @code{reg}, @code{mem} or
-constants which are just the operands.  The RTL structure of these
-insns is not sufficient to indicate what the insns actually do.  What
-@code{NOTICE_UPDATE_CC} should do when it sees one is just to run
-@code{CC_STATUS_INIT}.
-
-A possible definition of @code{NOTICE_UPDATE_CC} is to call a function
-that looks at an attribute (@pxref{Insn Attributes}) named, for example,
-@samp{cc}.  This avoids having detailed information about patterns in
-two places, the @file{md} file and in @code{NOTICE_UPDATE_CC}.
-@end defmac
-
 @node MODE_CC Condition Codes
 @subsection Representation of condition codes using registers
 @findex CCmode
@@ -4586,6 +4513,8 @@ If you don't define this, a reasonable default is used.
 
 @hook TARGET_USE_BY_PIECES_INFRASTRUCTURE_P
 
+@hook TARGET_OVERLAP_OP_BY_PIECES_P
+
 @hook TARGET_COMPARE_BY_PIECES_BRANCH_RATIO
 
 @defmac MOVE_MAX_PIECES
@@ -7905,8 +7834,7 @@ for cross-profiling.
 
 A C expression for the maximum number of instructions to execute via
 conditional execution instructions instead of a branch.  A value of
-@code{BRANCH_COST}+1 is the default if the machine does not use cc0, and
-1 if it does use cc0.
+@code{BRANCH_COST}+1 is the default.
 @end defmac
 
 @defmac IFCVT_MODIFY_TESTS (@var{ce_info}, @var{true_expr}, @var{false_expr})