--- gcc/gcc.texinfo	2018/04/24 16:45:37	1.1
+++ gcc/gcc.texinfo	2018/04/24 16:49:21	1.1.1.5
@@ -6,7 +6,7 @@
 @ifinfo
 This file documents the use and the internals of the GNU compiler.
 
-Copyright (C) 1988 Free Software Foundation, Inc.
+Copyright (C) 1988, 1989 Free Software Foundation, Inc.
 
 Permission is granted to make and distribute verbatim copies of
 this manual provided the copyright notice and this permission notice
@@ -39,12 +39,12 @@ Free Software Foundation instead of in t
 @sp 2
 @center Richard M. Stallman
 @sp 3
-@center last updated 3 October 1988
+@center last updated 24 Jan 1989
 @sp 1
-@center for version 1.29
+@center for version 1.33
 @page
 @vskip 0pt plus 1filll
-Copyright @copyright{} 1988 Free Software Foundation, Inc.
+Copyright @copyright{} 1988, 1989 Free Software Foundation, Inc.
 
 Permission is granted to make and distribute verbatim copies of
 this manual provided the copyright notice and this permission notice
@@ -58,7 +58,7 @@ distributed under the terms of a permiss
 
 Permission is granted to copy and distribute translations of this manual
 into another language, under the above conditions for modified versions,
-except that the section entitled ``GNU CC General Public License'' and
+<except that the section entitled ``GNU CC General Public License'' and
 this permission notice may be included in translations approved by the
 Free Software Foundation instead of in the original English.
 @end titlepage
@@ -306,6 +306,12 @@ the 9000 series 300.
 
 @item
 William Schelter did most of the work on the Intel 80386 support.
+
+@item
+Christopher Smith did the port for Convex machines.
+
+@item
+Paul Petersen wrote the machine description for the Alliant FX/8.
 @end itemize
 
 @node Options, Installation, Contributors, Top
@@ -318,19 +324,20 @@ very different from @samp{-d -r}.
 
 When you invoke GNU CC, it normally does preprocessing, compilation,
 assembly and linking.  File names which end in @samp{.c} are taken as C
-source to be preprocessed and compiled; compiler output files plus any
-input files with names ending in @samp{.s} are assembled; then the
-resulting object files, plus any other input files, are linked together to
-produce an executable.
+source to be preprocessed and compiled; file names ending in @samp{.i}
+are taken as preprocessor output to be compiled; compiler output files
+plus any input files with names ending in @samp{.s} are assembled; then
+the resulting object files, plus any other input files, are linked
+together to produce an executable.
 
 Command options allow you to stop this process at an intermediate stage.
 For example, the @samp{-c} option says not to run the linker.  Then the
 output consists of object files output by the assembler.
 
-Other command options are passed on to one stage.  Some options control
-the preprocessor and others the compiler itself.  Yet other options
-control the assembler and linker; these are not documented here because the
-GNU assembler and linker are not yet released.
+Other command options are passed on to one stage of processing.  Some
+options control the preprocessor and others the compiler itself.  Yet
+other options control the assembler and linker; these are not documented
+here, but you rarely need to use any of them.
 
 Here are the options to control the overall compilation process, including
 those that say whether to link, whether to assemble, and so on.
@@ -367,6 +374,12 @@ Compiler driver program prints the comma
 the preprocessor, compiler proper, assembler and linker.  Some of
 these are directed to print their own version numbers.
 
+@item -pipe
+Use pipes rather than temporary files for communication between the
+various stages of compilation.  This fails to work on some systems
+where the assembler is unable to read from a pipe; but the GNU
+assembler has no trouble.
+
 @item -B@var{prefix}
 Compiler driver program tries @var{prefix} as a prefix for each
 program it tries to run.  These programs are @file{cpp}, @file{cc1},
@@ -385,6 +398,12 @@ the @samp{-B} prefix, if needed.  If it
 standard prefixes above are tried, and that is all.  The file is left
 out of the link if it is not found by those means.  Most of the time,
 on most machines, you can do without it.
+
+You can get a similar result from the environment variable;
+@code{GCC_EXEC_PREFIX} if it is defined, its value is used as a prefix
+in the same way.  If both the @samp{-B} option and the
+@code{GCC_EXEC_PREFIX} variable are present, the @samp{-B} option is
+used first and the environment variable value second.
 @end table
 
 These options control the details of C compilation itself.
@@ -434,6 +453,11 @@ to @code{unsigned int}.
 Out-of-range floating point literals are not an error.
 
 @item
+All automatic variables not declared @code{register} are preserved by
+@code{longjmp}.  Ordinarily, GNU C follows ANSI C: automatic variables
+not declared @code{volatile} may be clobbered.
+
+@item
 In the preprocessor, comments convert to nothing at all, rather than
 to a space.  This allows traditional token concatenation.
 
@@ -497,9 +521,9 @@ GNU assembler and linker in order to wor
 This feature will probably be eliminated.  It was intended to enable
 GDB to read the symbol table faster, but it doesn't result in enough
 of a speedup to be worth the larger object files and executables.  We
-are working on other ways of making GDB start faster, which work with
-DBX format debugging information and could be made to work with SDB
-format.
+are working on other ways of making GDB start even faster, which work
+with DBX format debugging information and could be made to work with
+SDB format.
 
 @item -w
 Inhibit all warning messages.
@@ -562,6 +586,10 @@ another common case:
 @noindent
 This has no bug because @code{save_y} is used only if it is set.
 
+Some spurious warnings can be avoided if you declare as
+@code{volatile} all the functions you use that never return.
+@xref{Function Attributes}.
+
 @item
 A nonvolatile automatic variable might be changed by a call to
 @code{longjmp}.  These warnings as well are possible only in
@@ -590,6 +618,9 @@ foo (a)
 Spurious warnings can occur because GNU CC does not realize that
 certain functions (including @code{abort} and @code{longjmp})
 will never return.
+
+@item
+An expression-statement contains no side effects.
 @end itemize
 
 In the future, other useful warnings may also be enabled by this
@@ -604,7 +635,8 @@ to @code{int}.  Also warn about any @cod
 return-value in a function whose return-type is not @code{void}.
 
 @item -Wunused
-Warn whenever a local variable is unused aside from its declaration.
+Warn whenever a local variable is unused aside from its declaration,
+and whenever a function is declared static but never defined.
 
 @item -Wcomment
 Warn whenever a comment-start sequence @samp{/*} appears in a comment.
@@ -737,8 +769,58 @@ will assemble with the GNU assembler.
 Output code for g-format floating point numbers instead of d-format.
 @end table
 
+These @samp{-m} switches are supported on the Sparc:
+
+@table @samp
+@item -mfpu
+Generate output containing floating point instructions.  This is the
+default if you use the unmodified sources.
+
+@item -msoft-float
+Generate output containing library calls for floating point.
+
+@item -mno-epilogue
+Nonzero to generate separate return instructions for @code{return}
+statements.  This has both advantages and disadvantages; I don't
+recall what they are.
+
+@item -meager
+Do eager conditional branch scheduling to fill no-op slots.  This
+optimization is new, so we suspect it has bugs; some day it will be
+done by default, but it is optional now so you can test it when you
+are ready.
+
+@emph{Test it now}, and report the bugs; otherwise we won't find them,
+and this option may become the default with bugs still in it!
+@end table
+
+These @samp{-m} options are defined in the Convex machine description:
+
+@table @samp
+@item -mc1
+Generate output for a C1.  This is the default when the compiler is
+configured for a C1.
+
+@item -mc2
+Generate output for a C2.  This is the default when the compiler is
+configured for a C2.
+
+@item -margcount
+Generate code which puts an argument count in the word preceding each
+argument list.  Some nonportable Convex and Vax programs need this
+word.  (Debuggers don't; this info is in the symbol table.)
+
+@item -mnoargcount
+Omit the argument count word.  This is the default if you use the
+unmodified sources.
+@end table
+
 @item -f@var{flag}
-Specify machine-independent flags.  These are the flags:
+Specify machine-independent flags.  Most flags have both positive and
+negative forms; the negative form of @samp{-ffoo} would be
+@samp{-fno-foo}.  In the table below, only one of the forms is
+listed---the one which is not the default.  You can figure out the
+other form by either removing @samp{no-} or adding it.
 
 @table @samp
 @item -ffloat-store
@@ -818,6 +900,10 @@ uniquize them.  This is for compatibilit
 assume they can write into string constants.  Writing into string
 constants is a very bad idea; ``constants'' should be constant.
 
+@item -fcond-mismatch
+Allow conditional expressions with mismatched types in the second and
+third arguments.  The value of such an expression is void.
+
 @item -fno-function-cse
 Do not put function addresses in registers; make each instruction
 that calls a constant function contain the function's address
@@ -830,9 +916,15 @@ optimizations performed when this option
 @item -fvolatile
 Consider all memory references through pointers to be volatile.
 
+@item -fshared-data
+Requests that the data and non-@code{const} variables of this
+compilation be shared data rather than private data.  The distinction
+makes sense only on certain operating systems, where shared data is
+shared between processes running the same program, while private data
+exists in one copy per process.
+
 @item -funsigned-char
-Let the type @code{char} be the unsigned, like @code{unsigned
-char}.
+Let the type @code{char} be the unsigned, like @code{unsigned char}.
 
 Each kind of machine has a default for what @code{char} should
 be.  It is either like @code{unsigned char} by default or like
@@ -843,9 +935,15 @@ The type @code{char} is always a distinc
 @code{signed char} or @code{unsigned char}, even though its
 behavior is always just like one of those two.
 
+Note that this is equivalent to @samp{-fno-signed-char}, which is the
+negative form of @samp{-fsigned-char}.
+
 @item -fsigned-char
 Let the type @code{char} be signed, like @code{signed char}.
 
+Note that this is equivalent to @samp{-fno-unsigned-char}, which is
+the negative form of @samp{-funsigned-char}.
+
 @item -ffixed-@var{reg}
 Treat the register named @var{reg} as a fixed register; generated
 code should never refer to it (except perhaps as a stack pointer,
@@ -856,6 +954,9 @@ accepted are machine-specific and are de
 @code{REGISTER_NAMES} macro in the machine description macro
 file.
 
+This flag does not have a negative form, because it specifies a
+three-way choice.
+
 @item -fcall-used-@var{reg}
 Treat the register named @var{reg} as an allocatable register
 that is clobbered by function calls.  It may be allocated for
@@ -867,6 +968,9 @@ Use of this flag for a register that has
 in the machine's execution model, such as the stack pointer or
 frame pointer, will produce disastrous results.
 
+This flag does not have a negative form, because it specifies a
+three-way choice.
+
 @item -fcall-saved-@var{reg}
 Treat the register named @var{reg} as an allocatable register
 saved by functions.  It may be allocated even for temporaries or
@@ -879,6 +983,9 @@ frame pointer, will produce disastrous r
 
 A different sort of disaster will result from the use of this
 flag for a register in which function values may be returned.
+
+This flag does not have a negative form, because it specifies a
+three-way choice.
 @end table
 
 @item -d@var{letters}
@@ -918,6 +1025,10 @@ this option (though a rare few will requ
 without this option, certain GNU extensions and traditional C features
 are supported as well.  With this option, they are rejected.  There is
 no reason to @i{use} this option; it exists only to satisfy pedants.
+
+@item -static
+On Suns running version 4, this prevents linking with the shared
+libraries.  (@samp{-g} has the same effect.)
 @end table
 
 These options control the C preprocessor, which is run on each C source
@@ -1006,13 +1117,85 @@ Here is the procedure for installing GNU
 @item
 Edit @file{Makefile}.  If you are using HPUX, or any form of system V,
 you must make a few changes described in comments at the beginning of
-the file.
+the file.  Genix requires changes also.
 
 @item
 On a Sequent system, go to the Berkeley universe.
 
 @item
-Choose configuration files.
+Choose configuration files.  The easy way to do this is to run the
+command file @file{config.gcc} with a single argument, which is the
+name of the machine (and operating system, in some cases).
+
+Here is a list of the possible arguments:
+
+@table @samp
+@item vax
+Vaxes running BSD.
+@item vms
+Vaxes running VMS.
+@item vax-sysv
+Vaxes running system V.
+@item i386-sysv
+Intel 386 PCs running system V.
+@item i386-sysv-gas
+Intel 386 PCs running system V, using the GNU assembler and GNU
+linker.
+@item sequent-386
+Sequent with Intel 386 processors.
+@item sun2
+Sun 2 running system version 2 or 3.
+@item sun3
+Sun 3 running system version 2 or 3, with 68881.
+@item sun3-nfp
+Sun 3 running system version 2 or 3, without 68881.
+@item sun3-fpa
+Sun 3 running system version 2 or 3, with 68881 and fpa.
+@item sun4
+Sun 4 running system version 2 or 3.
+@item sun2-os4
+Sun 2 running system version 4.
+@item sun3-os4
+Sun 3 running system version 4, with 68881.
+@item sun3-nfp-os4
+Sun 3 running system version 4, without 68881.
+@item sun3-fpa-os4
+Sun 3 running system version 4, with 68881 and fpa.
+@item sun4-os4
+Sun 4 running system version 4.
+@item sun386
+Sun 386 (``roadrunner'').
+@item alliant
+Alliant FX/8 computer.  Currently, there are bugs in the support for
+floating point.  Also note that Alliant's version of dbx does not
+manage to work with the output from GNU CC.
+@item convex-c1
+Convex C1 computer.
+@item convex-c2
+Convex C2 computer.
+@item hp9k320
+HP 9000 series 300 using HPUX assembler.
+@item kp9k320g
+HP 9000 series 300 using GNU assembler, linker and debugger.
+This requires the HP-adapt package which is or will soon be
+available along with the linker.
+@item isi68
+ISI 68000 or 68020 system.
+@item news800
+Sony NEWS 68020 system.
+@item 3b1
+AT&T 3b1, a.k.a. 7300 PC.
+@item sequent-ns32k
+Sequent containing ns32000 processors.
+@item encore
+Encore ns32000 system.
+@item genix
+National Semiconductor ns32000 system.
+@item 88000
+Motorola 88000 processor.  This port is not finished.
+@end table
+
+Here we spell out what files need to be set up:
 
 @itemize @bullet
 @item
@@ -1021,21 +1204,24 @@ config file for the machine you are usin
 file is responsible for defining information about the host
 machine.  It includes @file{tm.h}.
 
-The file's name should be @file{config-@var{machine}.h}, with these
+The file's name should be @file{xm-@var{machine}.h}, with these
 exceptions:
 
 @table @file
-@item config-vms.h
+@item xm-vms.h
 for vaxen running VMS.
-@item config-vaxv.h
+@item xm-vaxv.h
 for vaxen running system V.
-@item config-i386v.h
+@item xm-i386v.h
 for Intel 80386's running system V.
-@item config-sun4.h
+@item xm-sunos4.h
 for Suns (model 2, 3 or 4) running @emph{operating system} version 4.
-@item config-hp9k3.h
+(Use @file{xm-m68k.h} or @file{xm-sparc.h} for version 3.)
+@item xm-sun386i.h
+for Sun roadrunner running any version of the operating system.
+@item xm-hp9k320.h
 for the HP 9000 series 300.
-@item config-gnx.h
+@item xm-genix.h
 for the ns32000 running Genix
 @end table
 
@@ -1053,13 +1239,18 @@ directly.  Instead, use one of these fil
 
 @table @file
 @item tm-sun3.h
-for Sun 3 machines.
+for Sun 3 machines with 68881.
+@item tm-sun3-fpa.h
+for Sun 3 machines with floating point accelerator.
+@item tm-sun3-nfp.h
+for Sun 3 machines with no hardware floating point.
 @item tm-sun2.h
 for Sun 2 machines.
 @item tm-3b1.h
 for AT&T 3b1 (aka 7300 Unix PC).
 @item tm-isi68.h
-for Integrated Solutions systems.
+for Integrated Solutions systems.  This file assumes you
+use the GNU assembler.
 @item tm-news800.h
 for SONY News systems.
 @item tm-hp9k320.h
@@ -1075,21 +1266,21 @@ instructions will appear here in the fut
 For the vax, use @file{tm-vax.h} on BSD Unix, @file{tm-vaxv.h} on
 system V, or @file{tm-vms.h} on VMS.@refill
 
-For the SPARC (Sun 4), use @file{tm-sparc.h}.
-
 For the Motorola 88000, use @file{tm-m88k.h}.  The support for the
 88000 has a few unfinished spots because there was no way to run the
-output.  Bugs are suspected in handling of branch-tables and in
-the function prologue and epilogue.
+output.  Bugs are suspected in handling of branch-tables and in the
+function prologue and epilogue.
 
 For the 80386, don't use @file{tm-i386.h} directly.  Use
 @file{tm-i386v.h} if the target machine is running system V,
-@file{tm-seq386.h} for a Sequent 386 system, or @file{tm-compaq.h} for
-a Compaq.
+@file{tm-i386gas.h} if it is running system V but you are using the
+GNU assembler and linker, @file{tm-seq386.h} for a Sequent 386 system,
+or @file{tm-compaq.h} for a Compaq, or @file{tm-sun386i.h} for a Sun
+386 system.
 
 For the 32000, use @file{tm-sequent.h} if you are using a Sequent
 machine, or @file{tm-encore.h} for an Encore machine, or
-@file{tm-gnx.h} if you are using Genix version 3; otherwise, perhaps
+@file{tm-genix.h} if you are using Genix version 3; otherwise, perhaps
 @file{tm-ns32k.h} will work for you.
 
 Note that Genix has bugs in @code{alloca} and @code{malloc}; you must
@@ -1100,7 +1291,9 @@ Note that Encore systems are supported o
 
 @item
 Make a symbolic link named @file{md} to the machine description
-pattern file (its name should be @file{@var{machine}.md}).
+pattern file.  Its name should be @file{@var{machine}.md}, but
+@var{machine} is often not the same as the name used in the
+@file{tm.h} file because the @file{md} files are more general.
 
 @item
 Make a symbolic link named @file{aux-output.c} to the output
@@ -1127,6 +1320,17 @@ properly without special pains.
 @item
 Build the compiler.  Just type @samp{make} in the compiler directory.
 
+Ignore any warnings you may see about ``statement not reached'' in the
+@file{insn-emit.c}; they are normal.  Any other compilation errors may
+represent bugs in the port to your machine or operating system, and
+should be investigated and reported (@pxref{Bugs}).
+
+@item
+If you are using COFF-encapsulation, you must convert @file{gnulib} to
+a GNU-format library at this point.  See the file @file{README-ENCAP}
+in the directory containing the GNU binary file utilities, for
+directions.
+
 @item
 Move the first-stage object files and executables into a subdirectory
 with this command:
@@ -1213,10 +1417,9 @@ Alternatively, on Sun systems and 4.3BSD
 include files by running the shell script @file{fixincludes}.  This
 installs modified, corrected copies of the files @file{ioctl.h},
 @file{ttychars.h} and many others, in a special directory where only
-GNU CC will normally look for them.
-
-See the file @file{fixincludes} for a list of all the files we know to
-require correction.
+GNU CC will normally look for them.  This script will work on various
+systems because it choose the files by searching all the system
+headers for the problem cases that we know about.
 @end enumerate
 
 If you cannot install the compiler's passes and run-time support in
@@ -1232,27 +1435,28 @@ by setting the Make variable @code{libdi
 @node VMS Install,, Installation, Installation
 @section Installing GNU CC on VMS
 
-The VMS version of GNU CC is distributed in an unusual tape format which
-consists of several tape files.  The first is a command file; the second is
-an executable program which reads Unix tar format; the third is another
-command file which uses this program to read the remainder of the tape.
-
-To load the tape, it suffices to mount it @samp{/foreign} and then do
-@samp{@@mta0:} to execute the command file at the beginning of the tape.
-
-The tape contains executables and object files as well as sources, so no
-compilation is necessary unless you change the sources.  (This is a good
-thing, since you probably don't have any other C compiler.)  If you must
+The VMS version of GNU CC is distributed in a backup saveset containing
+both source code and precompiled binaries.
+
+Sometimes the binaries will be from an older version that the sources,
+because we don't always have time to update them.  In this case, you
+should use the binaries you get to recompile the sources.  If you must
 recompile, here is how:
 
 @enumerate
 @item
-Copy the file @file{tm-vms.h} to @file{tm.h}, @file{config-vms.h} to
+Copy the file @file{tm-vms.h} to @file{tm.h}, @file{xm-vms.h} to
 @file{config.h}, @file{vax.md} to @file{md.} and @file{output-vax.c}
 to @file{aux-output.c}.@refill
 
 @item
 Type @samp{@@make} to do recompile everything.
+
+If you are compiling with a version of GCC older than 1.33, specify
+@samp{/DEFINE=("inline=")} as an option in all the compilations.  This
+requires editing all the @code{gcc} commands in @file{make-cc1.com}.
+(The older versions had problems supporting @code{inline}.)  Once you
+have a working 1.33 or newer GCC, you can change this file back.
 @end enumerate
 
 To install the @samp{GCC} command so you can use the compiler easily, in
@@ -1289,6 +1493,10 @@ file.c}, which is equivalent to the comm
 Unix.
 @end enumerate
 
+There is a known problem on VMS: @code{const} global variables don't
+work compatibly with the VMS C compiler; we don't know a way to get
+them to the linker properly.
+
 @node Trouble, Incompatibilities, Installation, Top
 @chapter Known Causes of Trouble with GNU CC.
 
@@ -1312,16 +1520,69 @@ representation.  But this does not work
 a different machine with an incompatible floating point format, or
 even a different byte-ordering.
 
-It is possible to fix this by writing machine-independent code which
-understands the floating point representation of the target machine.
-I am not interested in doing that much work to compensate for bugs
-in assemblers.
+In addition, correct constant folding of floating point values
+requires representing them in the target machine's format.
+(The C standard does not quite require this, but in practice
+it is the only way to win.)
+
+It is now possible to overcome these problems by defining macros such
+as @code{REAL_VALUE_TYPE}.  But doing so is a substantial amount of
+work for each target machine.  @xref{Cross-compilation}.
 
 @item
 DBX rejects some files produced by GNU CC, though it accepts similar
 constructs in output from PCC.  Until someone can supply a coherent
 description of what is valid DBX input and what is not, there is
 nothing I can do about these problems.  You are on your own.
+
+@item
+Users often think it is a bug when GNU CC reports an error for code
+like this:
+
+@example
+int foo (short);
+
+int foo (x)
+     short x;
+@{@dots{}@}
+@end example
+
+The error message is correct: this code really is erroneous, because the
+old-style non-prototype definition passes subword integers in their
+promoted types.  In other words, the argument is really an @code{int},
+not a @code{short}.  The correct prototype is this:
+
+@example
+int foo (int);
+@end example
+
+@item
+Users often think it is a bug when GNU CC reports an error for code
+like this:
+
+@example
+int foo (struct mumble *);
+
+struct mumble @{ @dots{} @};
+
+int foo (struct mumble *x)
+@{ @dots{} @}
+@end example
+
+This code really is erroneous, because the scope of @code{struct
+mumble} the prototype is limited to the argument list containing it.
+It does not refer to the @code{struct mumble} defined with file scope
+immediately below---they are two unrelated types with similar names in
+different scopes.
+
+But in the definition of @code{foo}, the file-scope type is used
+because that is available to be inherited.  Thus, the definition and
+the prototype do not match, and you get an error.
+
+This behavior may seem silly, but it's what the ANSI standard
+specifies.  It is easy enough for you to make your code work by moving
+the definition of @code{struct mumble} above the prototype.  I don't
+think it's worth being incompatible for.
 @end itemize
 
 @node Incompatibilities, Extensions, Trouble, Top
@@ -1347,7 +1608,7 @@ string its argument points to.
 Another consequence is that @code{sscanf} does not work on some
 systems when passed a string constant as its format control string.
 This is because @code{sscanf} incorrectly tries to write into the
-string constant.
+string constant.  Likewise @code{fscanf} and @code{scanf}.
 
 The best solution to these problems is to change the program to use
 @code{char}-array variables with initialization strings for these
@@ -1400,6 +1661,11 @@ in it.
 If you use the @samp{-W} option with the @samp{-O} option, you will
 get a warning when GNU CC thinks such a problem might be possible.
 
+The @samp{-traditional} option directs GNU C to put variables in
+the stack by default, rather than in registers, in functions that
+call @code{setjmp}.  This results in the behavior found in
+traditional C compilers.
+
 @item
 Declarations of external variables and functions within a block apply
 only to the block containing the declaration.  In other words, they
@@ -1494,6 +1760,11 @@ struct foo *nextfoo ();
 (Note that this assumes you are using the GNU preprocessor and not
 @samp{-traditional}, so that the ANSI antirecursion rules for macro
 expansions are effective.)
+
+On some machines, PCC uses a reentrant convention.  Then GNU CC uses
+the same convention except for structures of 1, 2, 4 or 8 bytes.  For
+such machines, there is no problem when returning structures of other
+sizes; the problem is insoluble for structures of those sizes.
 @end itemize
 
 @node Extensions, Bugs, Incompatibilities, Top
@@ -1515,14 +1786,18 @@ features in conditional compilation, che
 * Variable-Length::	Arrays whose length is computed at run time.
 * Subscripting::	Any array can be subscripted, even if not an lvalue.
 * Pointer Arith::	Arithmetic on @code{void}-pointers and function pointers.
+* Initializers::	Non-constant initializers.
 * Constructors::	Constructor expressions give structures, unions
 			 or arrays as values.
+* Function Attributes:: Declaring that functions have no side effects,
+			 or that they can never return.
 * Dollar Signs::        Dollar sign is allowed in identifiers.
 * Alignment::           Inquiring about the alignment of a type or variable.
 * Inline::              Defining inline functions (as fast as macros).
 * Extended Asm::	Assembler instructions with C expressions as operands.
 			 (With them you can define ``built-in'' functions.)
 * Asm Labels::		Specifying the assembler name to use for a C symbol.
+* Global Reg Vars::     Defining global variables which reside in registers.
 @end menu
 
 @node Statement Exprs, Naming Types, Extensions, Extensions
@@ -1907,7 +2182,7 @@ foo (float f, float g)
 @}
 @end example
 
-@node Constructors, Dollar Signs, Initializers, Extensions
+@node Constructors, Function Attributes, Initializers, Extensions
 @section Constructor Expressions
 
 GNU C supports constructor expressions.  A constructor looks like a cast
@@ -1957,7 +2232,59 @@ latter does the same thing an ordinary C
 output = ((int[]) @{ 2, x, 28 @}) [input];
 @end example
 
-@node Dollar Signs, Alignment, Constructors, Extensions
+@node Function Attributes, Dollar Signs, Constructors
+@section Declaring Attributes of Functions
+
+In GNU C, you declare certain things about functions called in your program
+which help the compiler optimize function calls.
+
+A few functions, such as @code{abort} and @code{exit}, cannot return.
+These functions should be declared @code{volatile}.  For example,
+
+@example
+extern volatile void abort ();
+@end example
+
+@noindent
+tells the compiler that it can assume that @code{abort} will not return.
+This makes slightly better code, but more importantly it helps avoid
+spurious warnings of uninitialized variables.
+
+Many functions do not examine any values except their arguments, and
+have no effects except the return value.  Such a function can be subject
+to common subexpression elimination and loop optimization just as an
+arithmetic operator would be.  These functions should be declared
+@code{const}.  For example,
+
+@example
+extern const void square ();
+@end example
+
+@noindent
+says that the hypothetical function @code{square} is safe to call
+fewer times than the program says.
+
+Note that a function that has pointer arguments and examines the data
+pointed to must @emph{not} be declared @code{const}.  Likewise, a
+function that calls a non-@code{const} function must not be
+@code{const}.
+
+Some people object to this feature, claiming that ANSI C's @code{#pragma}
+should be used instead.  There are two reasons I did not do this.
+
+@enumerate
+@item
+It is impossible to generate @code{#pragma} commands from a macro.
+
+@item
+The @code{#pragma} command is just as likely as these keywords to mean
+something else in another compiler.
+@end enumerate
+
+These two reasons apply to @emph{any} application whatever: as far as
+I can see, @code{#pragma} is never useful.
+
+@node Dollar Signs, Alignment, Function Attributes, Extensions
 @section Dollar Signs in Identifier Names
 
 In GNU C, you may use dollar signs in identifier names.  This is because
@@ -2058,16 +2385,21 @@ asm ("fsinx %1,%0" : "=f" (result) : "f"
 Here @code{angle} is the C expression for the input operand while
 @code{result} is that of the output operand.  Each has @samp{"f"} as its
 operand constraint, saying that a floating-point register is required.  The
-constraints use the same language used in the machine description
-(@pxref{Constraints}).
+@samp{=} in @samp{=f} indicates that the operand is an output; all output
+operands' constraints must use @samp{=}.  The constraints use the same
+language used in the machine description (@pxref{Constraints}).
 
 Each operand is described by an operand-constraint string followed by the C
 expression in parentheses.  A colon separates the assembler template from
 the first output operand, and another separates the last output operand
 from the first input, if any.  Commas separate output operands and separate
-inputs.  The number of operands is limited to the maximum number of
+inputs.  The total number of operands is limited to the maximum number of
 operands in any instruction pattern in the machine description.
 
+If there are no output operands, and there are input operands, then there
+must be two consecutive colons surrounding the place where the output
+operands would go.
+
 Output operand expressions must be lvalues; the compiler can check this.
 The input operands need not be lvalues.  The compiler cannot check whether
 the operands have data types that are reasonable for the instruction being
@@ -2076,9 +2408,6 @@ not know what it means, or whether it is
 extended @code{asm} feature is most often used for machine instructions
 that the compiler itself does not know exist.
 
-If there are no output operands, and there are input operands, then you
-should write two colons in a row where the output operands would go.
-
 The output operands must be write-only; GNU CC will assume that the values
 in these operands before the instruction are dead and need not be
 generated.  For an operand that is read-write, or in which not all bits are
@@ -2097,7 +2426,8 @@ asm ("combine %2,%0" : "=r" (foo) : "0"
 
 @noindent
 The constraint @samp{"0"} for operand 1 says that it must occupy the same
-location as operand 0.
+location as operand 0.  A digit in constraint is allowed only in an input
+operand, and it must refer to an output operand.
 
 Only a digit in the constraint can guarantee that one operand will be in
 the same place as another.  The mere fact that @code{foo} is the value of
@@ -2123,9 +2453,10 @@ This assumption may be false if the asse
 more than one instruction.  In such a case, use @samp{&} for each output
 operand that may not overlap an input.  @xref{Modifiers}.
 
-Some instructions clobber specific hard registers.  To describe this,
-write a third colon after the input operands, followed by the names of
-the clobbered hard registers (given as strings).  For example, on the vax,
+Some instructions clobber specific hard registers.  To describe this, write
+a third colon after the input operands, followed by the names of the
+clobbered hard registers (given as strings).  Here is a realistic example
+for the vax:
 
 @example
 asm volatile ("movc3 %0,%1,%2"
@@ -2134,6 +2465,21 @@ asm volatile ("movc3 %0,%1,%2"
               : "r0", "r1", "r2", "r3", "r4", "r5");
 @end example
 
+You can put multiple assembler instructions together in a single @code{asm}
+template, separated with semicolons.  The input operands are guaranteed not
+to use any of the clobbered registers, and neither will the output
+operands' addresses, so you can read and write the clobbered registers as
+many times as you like.  Here is an example of multiple instructions in a
+template; it assumes that the subroutine @code{_foo} accepts arguments in
+registers 9 and 10:
+
+@example
+asm ("movl %0,r9;movl %1,r10;call _foo"
+     : /* no outputs */
+     : "g" (from), "g" (to)
+     : "r9", "r10");
+@end example
+
 Usually the most convenient way to use these @code{asm} instructions is to
 encapsulate them in macros that look like functions.  For example,
 
@@ -2157,14 +2503,15 @@ example, if the desired type were @code{
 argument to an @code{int} variable named @code{__arg} would warn about
 using a pointer unless the caller explicitly casts it.
 
-GNU CC assumes for optimization purposes that these instructions have no
-side effects except to change the output operands.  This does not mean that
-instructions with a side effect cannot be used, but you must be careful,
-because the compiler may eliminate them if the output operands aren't used,
-or move them out of loops, or replace two with one if they constitute a
-common subexpression.  Also, if your instruction does have a side effect on
-a variable that otherwise appears not to change, the old value of the
-variable may be reused later if it happens to be found in a register.
+If an @code{asm} has output operands, GNU CC assumes for optimization
+purposes that the instruction has no side effects except to change the
+output operands.  This does not mean that instructions with a side effect
+cannot be used, but you must be careful, because the compiler may eliminate
+them if the output operands aren't used, or move them out of loops, or
+replace two with one if they constitute a common subexpression.  Also, if
+your instruction does have a side effect on a variable that otherwise
+appears not to change, the old value of the variable may be reused later if
+it happens to be found in a register.
 
 You can prevent an @code{asm} instruction from being deleted, moved or
 combined by writing the keyword @code{volatile} after the @code{asm}.  For
@@ -2175,6 +2522,9 @@ example:
 asm volatile ("set_priority %0": /* no outputs */ : "g" (x))
 @end example
 
+If there are no output operands, the instruction will not be deleted or
+moved.
+
 It is a natural idea to look for a way to give access to the condition
 code left by the assembler instruction.  However, when we attempted to
 implement this, we found no way to make it work reliably.  The problem
@@ -2184,7 +2534,7 @@ instructions would alter the condition c
 test it.  This problem doesn't arise for ordinary ``test'' and
 ``compare'' instructions because they don't have any output operands.
 
-@node Asm Labels,,Extended Asm, Extensions
+@node Asm Labels, Global Reg Vars, Extended Asm, Extensions
 @section Controlling Names Used in Assembler Code
 
 You can specify the name to be used in the assembler code for a C function
@@ -2222,6 +2572,88 @@ register name; that would produce comple
 CC does not as yet have the ability to store static variables in registers.
 Perhaps that will be added.
 
+@node Global Reg Vars,, Asm Labels, Extensions
+@section Global Variables in Registers
+
+A few programs, such as programming language interpreters, may have a
+couple of global variables that are accessed so often that it is worth
+while to reserve registers throughout the program just for them.
+
+You can define a global register variable in GNU C like this:
+
+@example
+register int *foo asm ("a5");
+@end example
+
+@noindent
+Here @code{a5} is the name of the register which should be used.  Choose a
+register which is normally saved and restored by function calls on your
+machine, so that library routines will not clobber it.
+
+Naturally the register name is cpu-dependent, so you would need to
+conditionalize your program according to cpu type.  The register
+@code{a5} would be a good choice on a 68000 for a variable of pointer
+type.  On machines with register windows, be sure to choose a ``global''
+register that is not affected by the function call mechanism.
+
+In addition, operating systems on one type of cpu may differ in how they
+name the registers; then you would need additional conditionals.  For
+example, some 68000 operating systems call this register @code{%a5}.
+
+Eventually there may be a way of asking the compiler to choose a register
+automatically, but first we need to figure out how it should choose and
+how to enable you to guide the choice.
+
+Defining a global register variable in a certain register reserves that
+register entirely for this use, at least within the current compilation.
+The register will not be allocated for any other purpose in the functions
+in the current compilation.  The register will not be saved and restored by
+these functions.  Stores into this register are never deleted even if they
+would appear to be dead, but references may be deleted or moved or
+simplified.
+
+It is not safe to access the global register variables from signal
+handlers, or from more than one thread of control, because the system
+library routines may temporarily use the register for other things (unless
+you recompile them specially for the task at hand).
+
+It is not safe for one function that uses a global register variable to
+call another such function @code{foo} by way of a third function
+@code{lose} that was compiled without knowledge of this variable (i.e. in a
+different source file in which the variable wasn't declared).  This is
+because @code{lose} might save the register and put some other value there.
+For example, you can't expect a global register variable to be available in
+the comparison-function that you pass to @code{qsort}, since @code{qsort}
+might have put something else in that register.  (If you are prepared to
+recompile @code{qsort} with the same global register variable, you can
+solve this problem.)
+
+If you want to recompile @code{qsort} or other source files which do not
+actually use your global register variable, so that they will not use that
+register for any other purpose, then it suffices to specify the compiler
+option @samp{-ffixed-@var{reg}}.  You need not actually add a global
+register declaration to their source code.
+
+A function which can alter the value of a global register variable cannot
+safely be called from a function compiled without this variable, because it
+could clobber the value the caller expects to find there on return.
+Therefore, the function which is the entry point into the part of the
+program that uses the global register variable must explicitly save and
+restore the value which belongs to its caller.
+
+On most machines, @code{longjmp} will restore to each global register
+variable the value it had at the time of the @code{setjmp}.  On some
+machines, however, @code{longjmp} will not change the value of global
+register variables.  To be portable, the function that called @code{setjmp}
+should make other arrangements to save the values of the global register
+variables, and to restore them if a @code{longjmp}.  This way, the the same
+thing will happen regardless of what @code{longjmp} does.
+
+All global register variable declarations must precede all function
+definitions.  If such a declaration could appear after function
+definitions, the declaration would be too late to prevent the register from
+being used for other purposes in the preceding functions.
+
 @node Bugs, Portability, Extensions, Top
 @chapter Reporting Bugs
 
@@ -2844,8 +3276,7 @@ the input file name.
 
 @item
 Jump optimization is repeated, this time including cross-jumping
-and deletion of no-op move instructions.  Machine-specific peephole
-optimizations are performed at the same time.
+and deletion of no-op move instructions.
 
 The option @samp{-dJ} causes a debugging dump of the RTL code after
 this pass.  This dump file's name is made by appending @samp{.jump2}
@@ -2854,7 +3285,8 @@ to the input file name.
 @item
 Final.  This pass outputs the assembler code for the function.  It is
 also responsible for identifying spurious test and compare
-instructions.  The function entry and exit sequences are generated
+instructions.  Machine-specific peephole optimizations are performed
+at the same time.  The function entry and exit sequences are generated
 directly as assembler code in this pass; they never exist as RTL.
 
 The source files are @file{final.c} plus @file{insn-output.c}; the
@@ -2993,7 +3425,7 @@ but when they appear in C code they are
 manual, they are shown as follows: @samp{const_int}.
 
 In a few contexts a null pointer is valid where an expression is normally
-wanted.  The written form of this is @samp{(nil)}.
+wanted.  The written form of this is @code{(nil)}.
 
 @node Accessors, Flags, RTL Objects, RTL
 @section Access to Operands
@@ -3286,6 +3718,39 @@ available machine modes machine-dependen
 about specific machine modes or their uses from the machine-independent
 code of the compiler.
 
+To help begin this process, the machine modes are divided into mode
+classes.  These are represented by the enumeration type @code{enum
+mode_class} defined in @file{rtl.h}.  The possible mode classes are:
+
+@table @code
+@item MODE_INT
+Integer modes.  By default these are @code{QImode}, @code{HImode},
+@code{SImode}, @code{DImode}, @code{TImode}, and also @code{BImode}.
+
+@item MODE_FLOAT
+Floating-point modes.  By default these are @code{QFmode},
+@code{HFmode}, @code{SFmode}, @code{DFmode} and @code{TFmode}, but the
+MC68881 also defines @code{XFmode} to be an 80-bit extended-precision
+floating-point mode.
+
+@item MODE_COMPLEX_INT
+Complex integer modes.  By default these are @code{CQImode},
+@code{CHImode}, @code{CSImode}, @code{CDImode} and @code{CTImode}.
+
+@item MODE_COMPLEX_FLOAT
+Complex floating-point modes.  By default these are @code{CQFmode},
+@code{CHFmode}, @code{CSFmode}, @code{CDFmode} and @code{CTFmode},
+
+@item MODE_FUNCTION
+Algol or Pascal function variables including a static chain.
+(These are not currently implemented).
+
+@item MODE_RANDOM
+This is a catchall mode class for modes which don't fit into the above
+classes.  Currently @code{VOIDmode}, @code{BLKmode} and @code{EPmode}
+are in @code{MODE_RANDOM}.
+@end table
+
 Here are some C macros that relate to machine modes:
 
 @table @code
@@ -3295,6 +3760,17 @@ Returns the machine mode of the RTX @var
 @item PUT_MODE (@var{x}, @var{newmode})
 Alters the machine mode of the RTX @var{x} to be @var{newmode}.
 
+@item NUM_MACHINE_MODES
+Stands for the number of machine modes available on the target
+machine.  This is one greater than the largest numeric value of any
+machine mode.
+
+@item GET_MODE_NAME (@var{m})
+Returns the name of mode @var{m} as a string.
+
+@item GET_MODE_CLASS (@var{m})
+Returns the mode class of mode @var{m}.
+
 @item GET_MODE_SIZE (@var{m})
 Returns the size in bytes of a datum of mode @var{m}.
 
@@ -3424,7 +3900,7 @@ If in addition the register number speci
 it actually represents several consecutive hardware registers starting
 with the specified one.
 
-Such multi-word hardware register @samp{reg} expressions may not be live
+Such multi-word hardware register @samp{reg} expressions must not be live
 across the boundary of a basic block.  The lifetime analysis pass does not
 know how to record properly that several consecutive registers are
 actually live there, and therefore register allocation would be confused.
@@ -3543,7 +4019,7 @@ Widening multiplication and same-size mu
 distinct and supported by different machine instructions; machines may
 support one but not the other.@refill
 
-@samp{mult} may be used for floating point division as well.
+@samp{mult} may be used for floating point multiplication as well.
 Then @var{m} is a floating point machine mode.
 
 @item (umult:@var{m} @var{x} @var{y})
@@ -3912,18 +4388,27 @@ default to clobber these registers, so t
 @samp{clobber} expressions to indicate this fact.  Also, each function
 call is assumed to have the potential to alter any memory location.
 
+When a @samp{clobber} expression for a register appears inside a
+@samp{parallel} with other side effects, GNU CC guarantees that the
+register is unoccupied both before and after that insn.  Therefore, it
+is safe for the assembler code produced by the insn to use the
+register as a temporary.  You can clobber either a specific hard
+register or a pseudo register; in the latter case, GNU CC will
+allocate a hard register that is available there for use as a
+temporary.
+
 @item (use @var{x})
 Represents the use of the value of @var{x}.  It indicates that the
 value in @var{x} at this point in the program is needed, even though
 it may not be apparent why this is so.  Therefore, the compiler will
-not attempt to delete instructions whose only effect is to store a
-value in @var{x}.  @var{x} must be a @samp{reg} expression.
+not attempt to delete previous instructions whose only effect is to
+store a value in @var{x}.  @var{x} must be a @samp{reg} expression.
 
 @item (parallel [@var{x0} @var{x1} @dots{}])
 Represents several side effects performed in parallel.  The square
 brackets stand for a vector; the operand of @samp{parallel} is a
 vector of expressions.  @var{x0}, @var{x1} and so on are individual
-side effects---expressions of code @samp{set}, @samp{call},
+side effect expressions---expressions of code @samp{set}, @samp{call},
 @samp{return}, @samp{clobber} or @samp{use}.@refill
 
 ``In parallel'' means that first all the values used in the individual
@@ -3939,16 +4424,34 @@ performed.  For example,
 says unambiguously that the values of hard register 1 and the memory
 location addressed by it are interchanged.  In both places where
 @code{(reg:SI 1)} appears as a memory address it refers to the value
-in register 1 @emph{before} the execution of the instruction.
+in register 1 @emph{before} the execution of the insn.
 
-Peephole optimization, which takes place in the last jump-optimization
-pass, can produce insns whose patterns consist of a @samp{parallel}
+It follows that it is @emph{incorrect} to use @samp{parallel} and
+expect the result of one @samp{set} to be available for the next one.
+For example, people sometimes attempt to represent a jump-if-zero
+instruction this way:
+
+@example
+(parallel [(set (cc0) (reg:SI 34))
+	   (set (pc) (if_then_else
+			(eq (cc0) (const_int 0))
+			(label_ref @dots{})
+			(pc)))])
+@end example
+
+@noindent
+But this is incorrect, because it says that the jump condition depends
+on the condition code value @emph{before} this instruction, not on the
+new value that is set by this instruction.
+
+Peephole optimization, which takes place in together with final assembly
+code output, can produce insns whose patterns consist of a @samp{parallel}
 whose elements are the operands needed to output the resulting
 assembler code--often @samp{reg}, @samp{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} may need
-to deal with such insns.
+However, the definition of the macro @code{NOTICE_UPDATE_CC} must
+deal with such insns if you define any peephole optimizations.
 
 @item (sequence [@var{insns} @dots{}])
 Represents a sequence of insns.  Each of the @var{insns} that appears
@@ -4226,12 +4729,12 @@ insns appear in it (as first operands of
 expressions).  Their order is not significant.
 
 The @code{REG_NOTES} field of an insn is a similar chain but of
-@samp{expr_list} expressions instead of @samp{insn_list}.  There are four
-kinds of register notes, which are distinguished by the machine mode of the
-@samp{expr_list}, which a register note is really understood as being an
-@code{enum reg_note}.  The first operand @var{op} of the @samp{expr_list}
-is data whose meaning depends on the kind of note.  Here are the four
-kinds:
+@samp{expr_list} expressions instead of @samp{insn_list}.  There are
+several kinds of register notes, which are distinguished by the machine
+mode of the @samp{expr_list}, which in a register note is really
+understood as being an @code{enum reg_note}.  The first operand @var{op}
+of the @samp{expr_list} is data whose meaning depends on the kind of
+note.  Here are the kinds of register note:
 
 @table @code
 @item REG_DEAD
@@ -4419,6 +4922,14 @@ the places they appear.  However, separa
 variables are occasionally made.
 
 @item
+When a single @code{asm} statement has multiple output operands,
+a distinct @code{asm_operands} RTX is made for each output operand.
+However, these all share the vector which contains the sequence of
+input operands.  Because this sharing is used later on to test whether
+two @code{asm_operands} RTX's come from the same statement, the sharing
+must be guaranteed to be preserved.
+
+@item
 No RTL object appears in more than one place in the RTL structure
 except as described above.  Many passes of the compiler rely on this
 by assuming that they can modify RTL objects in place without unwanted
@@ -4637,6 +5148,73 @@ It assumes that operand number @var{n} h
 a @samp{match_operand} appearing earlier in the recognition template,
 and it matches only an identical-looking expression.
 
+@item (match_operator:@var{m} @var{n} "@var{predicate}" [@var{operands}@dots{}])
+This pattern is a kind of placeholder for a variable RTL expression
+code.
+
+When constructing an insn, it stands for an RTL expression whose
+expression code is taken from that of operand @var{n}, and whose
+operands are constructed from the patterns @var{operands}.
+
+When matching an expression, it matches an expression if the function
+@var{predicate} returns nonzero on that expression @emph{and} the
+patterns @var{operands} match the operands of the expression.
+
+Suppose that the function @code{commutative_operator} is defined as
+follows, to match any expression whose operator is one of the six
+commutative arithmetic operators of RTL and whose mode is @var{mode}:
+
+@example
+int
+commutative_operator (x, mode)
+     rtx x;
+     enum machine_mode mode;
+@{
+  enum rtx_code code = GET_CODE (x);
+  if (GET_MODE (x) != mode)
+    return 0;
+  return (code == PLUS || code == MULT || code == UMULT
+          || code == AND || code == IOR || code == XOR);
+@}
+@end example
+
+Then the following pattern will match any RTL expression consisting
+of a commutative operator applied to two general operands:
+
+@example
+(match_operator:SI 2 "commutative_operator"
+  [(match_operand:SI 3 "general_operand" "g")
+   (match_operand:SI 4 "general_operand" "g")])
+@end example
+
+Here the vector @code{[@var{operands}@dots{}]} contains two patterns
+because the expressions to be matched all contain two operands.
+
+When this pattern does match, the two operands of the commutative
+operator are recorded as operands 3 and 4 of the insn.  (This is done
+by the two instances of @samp{match_operand}.)  Operand 2 of the insn
+will be the entire commutative expression: use @code{GET_CODE
+(operands[2])} to see which commutative operator was used.
+
+The machine mode @var{m} of @samp{match_operator} works like that of
+@samp{match_operand}: it is passed as the second argument to the
+predicate function, and that function is solely responsible for
+deciding whether the expression to be matched ``has'' that mode.
+
+When constructing an insn, argument 2 of the gen-function will specify
+the operation (i.e. the expression code) for the expression to be
+made.  It should be an RTL expression, whose expression code is copied
+into a new expression whose operands are arguments 3 and 4 of the
+gen-function.  The subexpressions of argument 2 are not used;
+only its expression code matters.
+
+There is no way to specify constraints in @samp{match_operator}.  The
+operand of the insn which corresponds to the @samp{match_operator}
+never has any constraints because it is never reloaded as a whole.
+However, if parts of its @var{operands} are matched by
+@samp{match_operand} patterns, those parts may have constraints of
+their own.
+
 @item (address (match_operand:@var{m} @var{n} "address_operand" ""))
 This complex of expressions is a placeholder for an operand number
 @var{n} in a ``load address'' instruction: an operand which specifies
@@ -4746,7 +5324,7 @@ vector may be @code{operands}, or it may
 that you declare locally and initialize yourself.
 
 When an insn pattern has multiple alternatives in its constraints, often
-the appearance of the assembler code determined mostly by which alternative
+the appearance of the assembler code is determined mostly by which alternative
 was matched.  When this is so, the C code can test the variable
 @code{which_alternative}, which is the ordinal number of the alternative
 that was actually satisfied (0 for the first, 1 for the second alternative,
@@ -4912,7 +5490,8 @@ input-output operand.
 Matching constraints work only in circumstances like that add insn.
 More precisely, the matching constraint must appear in an input-only
 operand and the operand that it matches must be an output-only operand
-with a lower number.
+with a lower number.  Thus, operand @var{n} must have @samp{=} in its
+constraint.
 
 For operands to match in a particular case usually means that they
 are identical-looking RTL expressions.  But in a few special cases
@@ -5009,7 +5588,7 @@ registers is safe provided its predicate
 An operand whose predicate accepts only constant values is safe
 provided its constraints include the letter @samp{i}.  If any possible
 constant value is accepted, then nothing less than @samp{i} will do;
-if the predicate is more selective, than the constraints may also be
+if the predicate is more selective, then the constraints may also be
 more selective.
 
 @item
@@ -5086,12 +5665,12 @@ When operands must be copied into regist
 never choose this alternative as the one to strive for.
 @end table
 
-When an insn pattern has multiple alternatives in its constraints,
-often the appearance of the assembler code determined mostly by which
+When an insn pattern has multiple alternatives in its constraints, often
+the appearance of the assembler code is determined mostly by which
 alternative was matched.  When this is so, the C code for writing the
 assembler code can use the variable @code{which_alternative}, which is
-the ordinal number of the alternative that was actually satisfied
-(0 for the first, 1 for the second alternative, etc.).  For example:
+the ordinal number of the alternative that was actually satisfied (0 for
+the first, 1 for the second alternative, etc.).  For example:
 
 @example
 (define_insn ""
@@ -5381,6 +5960,8 @@ The RTL pattern should look like this:
 Block move instruction.  The addresses of the destination and source
 strings are the first two operands, and both are in mode @code{Pmode}.
 The number of bytes to move is the third operand, in mode @var{m}.
+The fourth operand is the known shared alignment of the source and
+destination, in the form of a @code{const_int} rtx.
 
 @item @samp{cmpstr@var{m}}
 Block compare instruction, with operands like @samp{movstr@var{m}}
@@ -5754,7 +6335,7 @@ output a compare-and-branch instruction
 
 It also works to define patterns for compare-and-branch instructions.
 In optimizing compilation, the pair of compare and branch instructions
-will be combined accoprding to these patterns.  But this does not happen
+will be combined according to these patterns.  But this does not happen
 if optimization is not requested.  So you must use one of the solutions
 above in addition to any special patterns you define.
 
@@ -5789,9 +6370,9 @@ machine-specific information in this mac
 it must obey the same rules as in a @samp{define_insn}.
 
 In this skeleton, @var{insn-pattern-1} and so on are patterns to match
-consecutive instructions.  The optimization applies to a sequence of
-instructions when @var{insn-pattern-1} matches the first one,
-@var{insn-pattern-2} matches the next, and so on.@refill
+consecutive insns.  The optimization applies to a sequence of insns when
+@var{insn-pattern-1} matches the first one, @var{insn-pattern-2} matches
+the next, and so on.@refill
 
 @var{insn-pattern-1} and so on look @emph{almost} like the second operand
 of @code{define_insn}.  There is one important difference: this pattern is
@@ -5801,11 +6382,11 @@ vector.  If the @code{define_insn} patte
 then the @var{insn-pattern} must place the vector inside an explicit
 @code{parallel} RTX.@refill
 
-The operands of the instructions are matched with @code{match_operands} and
-@code{match_dup}, as usual).  What is not usual is that the operand numbers
-apply to all the instruction patterns in the definition.  So, you can check
-for identical operands in two instructions by using @code{match_operand}
-in one instruction and @code{match_dup} in the other.
+The operands of the insns are matched with @code{match_operands} and
+@code{match_dup}, as usual.  What is not usual is that the operand numbers
+apply to all the insn patterns in the definition.  So, you can check for
+identical operands in two insns by using @code{match_operand} in one insn
+and @code{match_dup} in the other.
 
 The operand constraints used in @code{match_operand} patterns do not have
 any direct effect on the applicability of the optimization, but they will
@@ -5813,16 +6394,17 @@ be validated afterward, so write constra
 the optimization is applied.  It is safe to use @code{"g"} for each
 operand.
 
-Once a sequence of instructions matches the patterns, the @var{condition}
-is checked.  This is a C expression which makes the final decision whether
-to perform the optimization (do so if the expression is nonzero).  If
+Once a sequence of insns matches the patterns, the @var{condition} is
+checked.  This is a C expression which makes the final decision whether to
+perform the optimization (we do so if the expression is nonzero).  If
 @var{condition} is omitted (in other words, the string is empty) then the
-optimization is applied to every sequence of instructions that matches the
+optimization is applied to every sequence of insns that matches the
 patterns.
 
-The defined peephole optimizations are applied after register allocation is
-complete.  Therefore, the optimizer can check which operands have ended up
-in which kinds of registers, just by looking at the operands.
+The defined peephole optimizations are applied after register allocation
+is complete.  Therefore, the peephole definition can check which
+operands have ended up in which kinds of registers, just by looking at
+the operands.
 
 The way to refer to the operands in @var{condition} is to write
 @code{operands[@var{i}]} for operand number @var{i} (as matched by
@@ -5839,20 +6421,19 @@ be used for the last time (from the valu
 of @code{PREV_INSN}), and @var{op} is the intermediate value (from
 @code{operands[@var{i}]}).@refill
 
-Applying the optimization means replacing the sequence of instructions with
-one new instruction.  The @var{template} controls ultimate output of
-assembler code for this combined instruction.  It works exactly like the
-template of a @code{define_insn}.  Operand numbers in this template are the
-same ones used in matching the original sequence of instructions.
+Applying the optimization means replacing the sequence of insns with one
+new insn.  The @var{template} controls ultimate output of assembler code
+for this combined insn.  It works exactly like the template of a
+@code{define_insn}.  Operand numbers in this template are the same ones
+used in matching the original sequence of insns.
 
 The result of a defined peephole optimizer does not need to match any of
-the instruction patterns, and it does not have an opportunity to match
-them.  The peephole optimizer definition itself serves as the instruction
-pattern to control how the instruction is output.
-
-Defined peephole optimizers are run in the last jump optimization pass, so
-the instructions they produce are never combined or rearranged
-automatically in any way.
+the insn patterns in the machine description; it does not even have an
+opportunity to match them.  The peephole optimizer definition itself serves
+as the insn pattern to control how the insn is output.
+
+Defined peephole optimizers are run as assembler code is being output,
+so the insns they produce are never combined or rearranged in any way.
 
 Here is an example, taken from the 68000 machine description:
 
@@ -5899,6 +6480,18 @@ movel d0,sp@@-
 fmoved sp@@+,fp0
 @end example
 
+@ignore
+If a peephole matches a sequence including one or more jump insns, you must
+take account of the flags such as @code{CC_REVERSED} which specify that the
+condition codes are represented in an unusual manner.  The compiler
+automatically alters any ordinary conditional jumps which occur in such
+situations, but the compiler cannot alter jumps which have been replaced by
+peephole optimizations.  So it is up to you to alter the assembler code
+that the peephole produces.  Supply C code to write the assembler output,
+and in this C code check the condition code status flags and change the
+assembler code as appropriate.
+@end ignore
+
 @node Expander Definitions,, Peephole Definitions, Machine Desc
 @section Defining RTL Sequences for Code Generation
 
@@ -6074,6 +6667,7 @@ compiler source files include @file{conf
 * Addressing Modes::    Defining addressing modes valid for memory operands.
 * Condition Code::      Defining how insns update the condition code.
 * Assembler Format::    Defining how to write insns and pseudo-ops to output.
+* Cross-compilation::   Handling floating point for cross-compilers.
 * Misc::                Everything else.
 @end menu
 
@@ -6087,12 +6681,21 @@ define the predefined macros that identi
 These macros will be predefined unless the @samp{-ansi} option is
 specified.
 
-For example, on the Sun, one can use the value
+In addition, a parallel set of macros are predefined, whose names are
+made by appending @samp{__} at the beginning and at the end.  These
+@samp{__} macros are permitted by the ANSI standard, so they are
+predefined regardless of whether @samp{-ansi} is specified.
+
+For example, on the Sun, one can use the following value:
 
 @example
 "-Dmc68000 -Dsun -Dunix"
 @end example
 
+The result is to define the macros @samp{__mc68000__}, @samp{__sun__}
+and @samp{__unix__} unconditionally, and the macros @samp{mc68000},
+@samp{sun} and @samp{unix} provided @samp{-ansi} is not specified.
+
 @item CPP_SPEC
 A C string constant that tells the GNU CC driver program options to
 pass to CPP.  It can also specify how to translate options you
@@ -6310,9 +6913,9 @@ on target flags.
 You need not define this macro if it has no work to do.
 
 If the usage of an entire class of registers depends on the target
-flags, you may indicate this to gcc by using this macro to modify
+flags, you may indicate this to GCC by using this macro to modify
 @code{fixed_regs} and @code{call_used_regs} to 1 for each of the
-registers in the classes which should not be used by gcc.  Also define
+registers in the classes which should not be used by GCC.  Also define
 the macro @code{REG_CLASS_FROM_LETTER} to return @code{NO_REGS} if it
 is called with a letter for a class that shouldn't be used.
 
@@ -6322,15 +6925,15 @@ controlled by target switches, then GCC
 these registers when the target switches are opposed to them.)
 
 @item OVERLAPPING_REGNO_P (@var{regno})
-If defined, this is a C expression whose value is @var{regno} is
-nonzero if hard register number @var{regno} is an overlapping
-register.  This means a hard register which overlaps a hard register
-with a different number.  (Such overlap is undesirable, but
-occasionally it allows a machine to be supported which otherwise could
-not be.)  This macro must return nonzero for @emph{all} the registers
-which overlap each other.  GNU CC can use an overlapping register only
-in certain limited ways.  It can be used for allocation within a basic
-block, and may be spilled for reloading; that is all.
+If defined, this is a C expression whose value is nonzero if hard
+register number @var{regno} is an overlapping register.  This means a
+hard register which overlaps a hard register with a different number.
+(Such overlap is undesirable, but occasionally it allows a machine to
+be supported which otherwise could not be.)  This macro must return
+nonzero for @emph{all} the registers which overlap each other.  GNU CC
+can use an overlapping register only in certain limited ways.  It can
+be used for allocation within a basic block, and may be spilled for
+reloading; that is all.
 
 If this macro is not defined, it means that none of the hard registers
 overlap each other.  This is the usual situation.
@@ -6461,9 +7064,9 @@ machine allows code to be generated with
 so saves some time or space.  Use 1 when there is no possible
 advantage to avoiding a frame pointer.
 
-In certain cases, the compiler does not know how to do without a frame
-pointer.  The compiler recognizes those cases and automatically gives
-the function a frame pointer regardless of what
+In certain cases, the compiler does not know how to produce valid code
+without a frame pointer.  The compiler recognizes those cases and
+automatically gives the function a frame pointer regardless of what
 @code{FRAME_POINTER_REQUIRED} says.  You don't need to worry about
 them.@refill
 
@@ -7100,17 +7703,41 @@ executed at run time, so it may be empty
 @section Library Subroutine Names
 
 @table @code
+@item MULSI3_LIBCALL
+A C string constant giving the name of the function to call for
+multiplication of one signed full-word by another.  If you do not
+define this macro, the default name is used, which is @code{__mulsi3},
+a function defined in @file{gnulib}.
+
+@item UMULSI3_LIBCALL
+A C string constant giving the name of the function to call for
+multiplication of one unsigned full-word by another.  If you do not
+define this macro, the default name is used, which is
+@code{__umulsi3}, a function defined in @file{gnulib}.
+
+@item DIVSI3_LIBCALL
+A C string constant giving the name of the function to call for
+division of one signed full-word by another.  If you do not define
+this macro, the default name is used, which is @code{__divsi3}, a
+function defined in @file{gnulib}.
+
 @item UDIVSI3_LIBCALL
 A C string constant giving the name of the function to call for
-division of a full-word by a full-word.  If you do not define this
-macro, the default name is used, which is @code{_udivsi3}, a function
-defined in @file{gnulib}.
+division of one unsigned full-word by another.  If you do not define
+this macro, the default name is used, which is @code{__udivsi3}, a
+function defined in @file{gnulib}.
+
+@item MODSI3_LIBCALL
+A C string constant giving the name of the function to call for the
+remainder in division of one signed full-word by another.  If you do
+not define this macro, the default name is used, which is
+@code{__modsi3}, a function defined in @file{gnulib}.
 
 @item UMODSI3_LIBCALL
 A C string constant giving the name of the function to call for the
-remainder in division of a full-word by a full-word.  If you do not
-define this macro, the default name is used, which is @code{_umodsi3},
-a function defined in @file{gnulib}.
+remainder in division of one unsigned full-word by another.  If you do
+not define this macro, the default name is used, which is
+@code{__umodsi3}, a function defined in @file{gnulib}.
 
 @item TARGET_MEM_FUNCTIONS
 Define this macro if GNU CC should generate calls to the System V
@@ -7118,7 +7745,7 @@ Define this macro if GNU CC should gener
 rather than the BSD functions @code{bcopy} and @code{bzero}.
 @end table
 
-@node Addressing Modes, Misc, Library Names, Machine Macros
+@node Addressing Modes, Cross-compilation, Library Names, Machine Macros
 @section Addressing Modes
 
 @table @code
@@ -7177,7 +7804,7 @@ need have two variants; the higher level
 whether strict or not.@refill
 
 @item REG_OK_FOR_BASE_P (@var{x})
-A C expression that is nonzero if @var{x} (asumed to be a @code{reg}
+A C expression that is nonzero if @var{x} (assumed to be a @code{reg}
 RTX) is valid for use as a base register.  For hard registers, it
 should always accept those which the hardware permits and reject the
 others.  Whether the macro accepts or rejects pseudo registers must be
@@ -7186,7 +7813,7 @@ requires two variant definitions, of whi
 controls the one actually used.
 
 @item REG_OK_FOR_INDEX_P (@var{x})
-A C expression that is nonzero if @var{x} (asumed to be a @code{reg}
+A C expression that is nonzero if @var{x} (assumed to be a @code{reg}
 RTX) is valid for use as an index register.
 
 The difference between an index register and a base register is that
@@ -7245,7 +7872,106 @@ either @var{x} is a @samp{const_double}
 @samp{const_double} is valid and anything @code{CONSTANT_P} is valid.@refill
 @end table
 
-@node Misc, Condition Code, Addressing Modes, Machine Macros
+@node Cross-compilation, Misc, Addressing Modes, Machine Macros
+@section Cross Compilation and Floating-Point Format
+
+While all modern machines use 2's compliment representation for integers,
+there are a variety of representations for floating point numbers.  This
+means that in a cross-compiler the representation of floating point numbers
+in the compiled program may be different from that used in the machine
+doing the compilation.
+
+Because different representation systems may offer different amounts of
+range and precision, the cross compiler cannot safely use the host
+machine's floating point arithmetic.  Therefore, floating point constants
+must be represented in the target machine's format.  This means that the
+cross compiler cannot use @code{atof} to parse a floating point constant;
+it must have its own special routine to use instead.  Also, constant
+folding must emulate the target machine's arithmetic (or must not be done
+at all).
+
+The macros in the following table should be defined only if you are cross
+compiling between different floating point formats.
+
+Otherwise, don't define them. Then default definitions will be set up which
+use @code{double} as the data type, @code{==} to test for equality, etc.
+
+You don't need to worry about how many times you use an operand of any
+of these macros.  The compiler never uses operands which have side effects.
+
+@table @code
+@item REAL_VALUE_TYPE
+A macro for the C data type to be used to hold a floating point value
+in the target machine's format.  Typically this would be a
+@code{struct} containing an array of @code{int}.
+
+@item REAL_VALUES_EQUAL (@var{x}, @var{y})
+A macro for a C expression which compares for equality the two values,
+@var{x} and @var{y}, both of type @code{REAL_VALUE_TYPE}.
+
+@item REAL_VALUES_LESS (@var{x}, @var{y})
+A macro for a C expression which tests whether @var{x} is less than
+@var{y}, both values being of type @code{REAL_VALUE_TYPE} and
+interpreted as floating point numbers in the target machine's
+representation.
+
+@item REAL_VALUE_LDEXP (@var{x}, @var{scale})
+A macro for a C expression which performs the standard library
+function @code{ldexp}, but using the target machine's floating point
+representation.  Both @var{x} and the value of the expression have
+type @code{REAL_VALUE_TYPE}.  The second argument, @var{scale}, is an
+integer.
+
+@item REAL_VALUE_ATOF (@var{string})
+A macro for a C expression which converts @var{string}, an expression
+of type @code{char *}, into a floating point number in the target
+machine's representation.  The value has type @code{REAL_VALUE_TYPE}.
+@end table
+
+Define the following additional macros if you want to make floating
+point constant folding work while cross compiling.  If you don't
+define them, cross compilation is still possible, but constant folding
+will not happen for floating point values.
+
+@table @code
+@item REAL_ARITHMETIC (@var{output}, @var{code}, @var{x}, @var{y})
+A macro for a C statement which calculates an arithmetic operation of
+the two floating point values @var{x} and @var{y}, both of type
+@code{REAL_VALUE_TYPE} in the target machine's representation, to
+produce a result of the same type and representation which is stored
+in @var{output} (which will be a variable).
+
+The operation to be performed is specified by @var{code}, a tree code
+which will always be one of the following: @code{PLUS_EXPR},
+@code{MINUS_EXPR}, @code{MULT_EXPR}, @code{RDIV_EXPR},
+@code{MAX_EXPR}, @code{MIN_EXPR}.@refill
+
+The expansion of this macro is responsible for checking for overflow.
+If overflow happens, the macro expansion should execute the statement
+@code{return 0;}, which indicates the inability to perform the
+arithmetic operation requested.
+
+@item REAL_VALUE_NEGATE (@var{x})
+A macro for a C expression which returns the negative of the floating
+point value @var{x}.  Both @var{x} and the value of the expression
+have type @code{REAL_VALUE_TYPE} and are in the target machine's
+floating point representation.
+
+There is no way for this macro to report overflow, since overflow
+can't happen in the negation operation.
+
+@item REAL_VALUE_TO_INT (@var{low}, @var{high}, @var{x})
+A macro for a C expression which converts a floating point value
+@var{x} into a double-precision integer which is then stored into
+@var{low} and @var{high}, two variables of type @var{int}.
+
+@item REAL_VALUE_FROM_INT (@var{x}, @var{low}, @var{high})
+A macro for a C expression which converts a double-precision integer
+found in @var{low} and @var{high}, two variables of type @var{int},
+into a floating point value which is then stored into @var{x}.
+@end table
+
+@node Misc, Condition Code, Cross-compilation, Machine Macros
 @section Miscellaneous Parameters
 
 @table @code
@@ -7481,6 +8207,11 @@ the very beginning of the command given
 If this macro is not defined, a default is provided that loads the
 standard C startup file from the usual place.  See @file{gcc.c}.
 
+@item STANDARD_STARTFILE_PREFIX
+Define this macro as a C string constant if you wish to override the
+standard choice of @file{/lib/} as the default prefix for where to
+find the startup files such as @file{crt0.o}.
+
 @item ASM_FILE_START (@var{stream})
 A C expression which outputs to the stdio stream @var{stream}
 some appropriate text to go at the start of an assembler file.
@@ -7655,6 +8386,15 @@ insn, and @var{num} is the label-number
 If this macro is not defined, nothing special is output at the end of
 the jump-table.
 
+@item ASM_OUTPUT_ALIGN_CODE (@var{file})
+A C expression to output text to align the location counter in the way
+that is desirable at a point in the code that is reached only by
+jumping.
+
+This macro need not be defined if you don't want any special alignment
+to be done at such a time.  Most machine descriptions do not currently
+define the macro.
+
 @item ASM_FORMAT_PRIVATE_NAME (@var{outvar}, @var{name}, @var{number})
 A C expression to assign to @var{outvar} (which is a variable of type
 @code{char *}) a newly allocated string made from the string
@@ -7900,10 +8640,10 @@ definitions are correct for most assembl
 @node Config,, Machine Macros, Top
 @chapter The Configuration File
 
-The configuration file @file{config-@var{machine}.h} contains macro
-definitions that describe the machine and system on which the compiler is
-running.  Most of the values in it are actually the same on all machines
-that GNU CC runs on, so most all configuration files are identical.  But
+The configuration file @file{xm-@var{machine}.h} contains macro definitions
+that describe the machine and system on which the compiler is running.
+Most of the values in it are actually the same on all machines that GNU CC
+runs on, so large parts of all configuration files are identical.  But
 there are some macros that vary:
 
 @table @code
@@ -7916,5 +8656,10 @@ A C expression for the status code to be
 exits without serious errors.
 @end table
 
+In addition, configuration files for system V define @code{bcopy},
+@code{bzero} and @code{bcmp} as aliases.  Some files define @code{alloca}
+as a macro when compiled with GNU CC, in order to take advantage of the
+benefit of GNU CC's built-in @code{alloca}.
+
 @contents
 @bye