2.95.3, test release 2

46 files changed, 3695 insertions, 1572 deletions

diff --git a/gnu/egcs/FAQ b/gnu/egcs/FAQ
index 7d861f757b3..d29e31fd9a4 100644
--- a/gnu/egcs/FAQ
+++ b/gnu/egcs/FAQ
@@ -1,17 +1,17 @@
 
                        GCC Frequently Asked Questions
-                                      
+
    The latest version of this document is always available at
    [1]http://www.gnu.org/software/gcc/faq.html.
-   
+
    This FAQ tries to answer specific questions concerning GCC. For
    general information regarding C, C++, resp. Fortran please check the
    [2]comp.lang.c FAQ, [3]comp.lang.c++ FAQ, [4]comp.std.c++ FAQ, and the
    [5]Fortran Information page.
      _________________________________________________________________
-   
+
                                    Questions
-                                       
+
     1. [6]General information
          1. [7]What is the relationship between GCC and EGCS
          2. [8]What is the relationship between GCC and Cygnus
@@ -63,9 +63,9 @@
             them
         16. [51]What is libstdc++-v3 and how can I use it with g++?
      _________________________________________________________________
-   
+
                               General information
-                                       
+
 What is the relationship between GCC and EGCS
 
    In 1990/1991 gcc version 1 had reached a point of stability. For the
@@ -73,40 +73,40 @@ What is the relationship between GCC and EGCS
    in its design that would be difficult to resolve, so a major effort
    was made to resolve those limitiations and gcc version 2 was the
    result.
-   
+
    When we had gcc2 in a useful state, development efforts on gcc1
    stopped and we all concentrated on making gcc2 better than gcc1 could
    ever be. This is the kind of step forward we wanted to make with the
    EGCS project when it was formed in 1997.
-   
+
    In April 1999 the Free Software Foundation officially halted
    development on the gcc2 compiler and appointed the EGCS project as the
    official GCC maintainers.
-   
+
    We are in the process of merging GCC and EGCS, which will take some
    time. The net result will be a single project which will carry forward
    GCC development under the ultimate control of the [52]GCC Steering
    Committee.
      _________________________________________________________________
-   
+
 What is the relationship between GCC and Cygnus
 
    It is a common mis-conception that Cygnus controls either directly or
    indirectly GCC.
-   
+
    While Cygnus does donate hardware, network connections, code and
    developer time to GCC development, Cygnus does not control GCC.
-   
+
    Overall control of GCC is in the hands of the [53]GCC Steering
    Committee which includes people from a variety of different
    organizations and backgrounds. The purpose of the steering committee
    is to make decisions in the best interest of GCC and to help ensure
    that no individual or company has control over the project.
-   
+
    To summarize, Cygnus contributes to GCCproject, but does not exert a
    controlling influence over GCC.
      _________________________________________________________________
-   
+
 What is an open development model?
 
    With GCC, we are going to try a bazaar style[54][1] approach to its
@@ -115,34 +115,34 @@ What is an open development model?
    mailing list. All of the discussions on the development mailing list
    are available via the web. We're going to be making releases with a
    much higher frequency than they have been made in the past.
-   
+
    In addition to weekly snapshots of the GCC development sources, we
    have the sources readable from a CVS server by anyone. Furthermore we
    are using remote CVS to allow remote maintainers write access to the
    sources.
-   
+
    There have been many potential gcc developers who were not able to
    participate in gcc development in the past. We want these people to
    help in any way they can; we ultimately want GCC to be the best
    compiler in the world.
-   
+
    A compiler is a complicated piece of software, there will still be
    strong central maintainers who will reject patches, who will demand
    documentation of implementations, and who will keep the level of
    quality as high as it is today. Code that could use wider testing may
    be integrated--code that is simply ill-conceived won't be.
-   
+
    GCC is not the first piece of software to use this open development
    process; FreeBSD, the Emacs lisp repository, and the Linux kernel are
    a few examples of the bazaar style of development.
-   
+
    With GCC, we will be adding new features and optimizations at a rate
    that has not been done since the creation of gcc2; these additions
    will inevitably have a temporarily destabilizing effect. With the help
    of developers working together with this bazaar style development, the
    resulting stability and quality levels will be better than we've had
    before.
-   
+
      _[1]_ We've been discussing different development models a lot over
      the past few months. The paper which started all of this introduced
      two terms: A _cathedral_ development model versus a _bazaar_
@@ -150,7 +150,7 @@ What is an open development model?
      called ``[55]The Cathedral and the Bazaar''. The paper is a useful
      starting point for discussions.
      _________________________________________________________________
-   
+
 How to report bugs
 
    There are complete instructions in the [56]gcc info manual, section
@@ -158,12 +158,12 @@ How to report bugs
    the GNU info program is installed on your system by `info --node
    "(gcc)Bugs"'. Or see the file [57]BUGS included with the GCC source
    code.
-   
+
    Before you report a bug for the _C++ compiler_, please check the
    [58]list of well-known bugs. If you want to report a bug with _egcs
    1.0.x_ or _egcs 1.1.x_, we strongly recommend upgrading to the current
    release first.
-   
+
    In short, if GCC says Internal compiler error (or any other error that
    you'd like us to be able to reproduce, for that matter), please mail a
    bug report to [59]gcc-bugs@gcc.gnu.org or [60]bug-gcc@gnu.org
@@ -173,31 +173,31 @@ How to report bugs
      * All options you passed to the compiler
      * Preprocessed output of the source file that caused the compiler
        error
-       
+
    All this can normally be accomplished by mailing the command line, the
    output of the command, and the resulting `_your-file_.i' for C, or
    `_your-file_.ii' for C++, corresponding to:
-   
+
    gcc -v --save-temps _all-your-options_ _your-file_.c
-   
+
    Typically the CPP output (extension .i for C or .ii for C++) will be
    large, so please compress the resulting file with one of the popular
    compression programs such as bzip2, gzip, zip, pkzip or compress (in
    decreasing order of preference). Use maximum compression (-9) if
    available. Please include the compressed CPP output in your bug
    report.
-   
+
    Since we're supposed to be able to re-create the assembly output
    (extension .s), you usually don't have to include it in the bug
    report, although you may want to post parts of it to point out
    assembly code you consider to be wrong.
-   
+
    Whether to use MIME attachments or uuencode is up to you. In any case,
    make sure the compiler command line, version and error output are in
    plain text, so that we don't have to decode the bug report in order to
    tell who should take care of it. A meaningful subject indicating
    language and platform also helps.
-   
+
    The gcc lists have message size limits (100 kbytes) and bug reports
    over those limits will currently be bounced. We're trying to find a
    way to allow larger bug reports to be posted, but this is currently
@@ -209,7 +209,7 @@ How to report bugs
    output in multiple files (using split, for example) and post them in
    separate messages, but we prefer to have self-contained bug reports in
    single messages.
-   
+
    If you fail to supply enough information for a bug report to be
    reproduced, someone will probably ask you to post additional
    information (or just ignore your bug report, if they're in a bad day,
@@ -220,7 +220,7 @@ How to report bugs
    supplied in the incomplete bug report (including the preprocessor
    output), so that the new bug report is self-contained.
      _________________________________________________________________
-   
+
 How do I get a bug fixed or a feature added?
 
    There are lots of ways to get something fixed. The list below may be
@@ -247,44 +247,44 @@ How do I get a bug fixed or a feature added?
        of your changes, your code may or may not ever make it into an
        official release of GCC.
      _________________________________________________________________
-   
+
                                  Installation
-                                       
+
 Problems building the Fortran compiler
 
    The Fortran front end can not be built with most vendor compilers; it
    must be built with gcc. As a result, you may get an error if you do
    not follow the install instructions carefully.
-   
+
    In particular, instead of using "make" to build GCC, you should use
    "make bootstrap" if you are building a native compiler or "make cross"
    if you are building a cross compiler.
-   
+
    It has also been reported that the Fortran compiler can not be built
    on Red Hat 4.X GNU/Linux for the Alpha. Fixing this may require
    upgrading binutils or to Red Hat 5.0; we'll provide more information
    as it becomes available.
      _________________________________________________________________
-   
+
 How to install multiple versions of gcc
 
    It may be desirable to install multiple versions of the compiler on
    the same system. This can be done by using different prefix paths at
    configure time and a few symlinks.
-   
+
    Basically, configure the two compilers with different --prefix
    options, then build and install each compiler. Assume you want "gcc"
    to be the latest compiler and available in /usr/local/bin; also assume
    that you want "gcc2" to be the older gcc2 compiler and also available
    in /usr/local/bin.
-   
+
    The easiest way to do this is to configure the new GCC with
    --prefix=/usr/local/gcc and the older gcc2 with
    --prefix=/usr/local/gcc2. Build and install both compilers. Then make
    a symlink from /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from
    /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links
    for the "g++", "c++" and "g77" compiler drivers.
-   
+
    An alternative to using symlinks is to configure with a
    --program-transform-name option. This option specifies a sed command
    to process installed program names with. Using it you can, for
@@ -303,46 +303,46 @@ How to install multiple versions of gcc
    /usr/local/gcc/bin with names prefixed by "new-". You can use
    --program-transform-name if you have multiple versions of GCC, and
    wish to be sure about which version you are invoking.
-   
+
    If you use --prefix, GCC may have difficulty locating a GNU assembler
    or linker on your system, [62]GCC can not find GNU as/GNU ld explains
    how to deal with this.
      _________________________________________________________________
-   
+
 Dynamic linker is unable to find GCC libraries
 
    This problem manifests itself by programs not finding shared libraries
    they depend on when the programs are started. Note this problem often
    manifests itself with failures in the libio/libstdc++ tests after
    configuring with --enable-shared and building GCC.
-   
+
    GCC does not specify a runpath so that the dynamic linker can find
    dynamic libraries at runtime.
-   
+
    The short explanation is that if you always pass a -R option to the
    linker, then your programs become dependent on directories which may
    be NFS mounted, and programs may hang unnecessarily when an NFS server
    goes down.
-   
+
    The problem is not programs that do require the directories; those
    programs are going to hang no matter what you do. The problem is
    programs that do not require the directories.
-   
+
    SunOS effectively always passed a -R option for every -L option; this
    was a bad idea, and so it was removed for Solaris. We should not
    recreate it.
-   
+
    However, if you feel you really need such an option to be passed
    automatically to the linker, you may add it to the gcc specs file.
    This file can be found in the same directory that contains cc1 (run
    gcc -print-prog-name=cc1 to find it). You may add linker flags such as
    -R or -rpath, depending on platform and linker, to the *link or *lib
    specs.
-   
+
    Another alterative is to install a wrapper script around gcc, g++ or
    ld that adds the appropriate directory to the environment variable
    LD_RUN_PATH or equivalent (again, it's platform-dependent).
-   
+
    Yet another option, that works on a few platforms, is to hard-code the
    full pathname of the library into its soname. This can only be
    accomplished by modifying the appropriate .ml file within
@@ -350,7 +350,7 @@ Dynamic linker is unable to find GCC libraries
    so that $(libdir)/ appears just before the library name in -soname or
    -h options.
      _________________________________________________________________
-   
+
 GCC can not find GNU as/GNU ld
 
    GCC searches the PATH for an assembler and a loader, but it only does
@@ -359,19 +359,19 @@ GCC can not find GNU as/GNU ld
    which the system asembler and loader can be found, you may have to
    take one of the following actions to arrange that gcc uses the GNU
    versions of those programs.
-   
+
    To ensure that GCC finds the GNU assembler (the GNU loader), which are
    required by [63]some configurations, you should configure these with
    the same --prefix option as you used for GCC. Then build & install GNU
    as (GNU ld) and proceed with building GCC.
-   
+
    Another alternative is to create links to GNU as and ld in any of the
    directories printed by the command `gcc -print-search-dirs | grep
    '^programs:''. The link to `ld' should be named `real-ld' if `ld'
    already exists. If such links do not exist while you're compiling GCC,
    you may have to create them in the build directories too, within the
    gcc directory _and_ in all the gcc/stage* subdirectories.
-   
+
    GCC 2.95 allows you to specify the full pathname of the assembler and
    the linker to use. The configure flags are `--with-as=/path/to/as' and
    `--with-ld=/path/to/ld'. GCC will try to use these pathnames before
@@ -382,7 +382,7 @@ GCC can not find GNU as/GNU ld
    you to override the search path for assembler and linker with
    command-line options -B/path/ if the specified filenames exist.
      _________________________________________________________________
-   
+
 cpp: Usage:... Error
 
    If you get an error like this when building GCC (particularly when
@@ -396,27 +396,27 @@ cpp: Usage:... Error
    '.', look for an empty pathname in those variables. Note that ':' at
    either the start or end of these variables is an implicit '.' and will
    cause problems.
-   
+
    Also note '::' in these paths will also cause similar problems.
      _________________________________________________________________
-   
+
                               Testsuite problems
-                                       
+
 Why is there no testsuite in GCC 2.95
 
    The GCC testsuite is not included in the GCC 2.95 release due to the
    uncertain copyright status of some tests.
-   
+
    The GCC team will be reviewing the entire testsuite to find and remove
    any tests with uncertain copyright status. Once those tests are
    removed from the testsuite, the testsuite as a whole will be
    copyrighted under the terms of the GPL and included in future GCC
    releases.
-   
+
    It is believed that only a few tests have uncertain copyright status
    and thus only a few tests will need to be removed from the testsuite.
      _________________________________________________________________
-   
+
 Unable to run the testsuite
 
    If you get a message about unable to find "standard.exp" when trying
@@ -425,7 +425,7 @@ Unable to run the testsuite
    [64]dejagnu snapshot available until a new version of dejagnu can be
    released.
      _________________________________________________________________
-   
+
 How do I pass flags like -fnew-abi to the testsuite?
 
    If you invoke runtest directly, you can use the --tool_opts option,
@@ -436,7 +436,7 @@ How do I pass flags like -fnew-abi to the testsuite?
    e.g:
   make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++
      _________________________________________________________________
-   
+
 How can I run the test suite with multiple options?
 
    If you invoke runtest directly, you can use the --target_board option,
@@ -449,21 +449,21 @@ How can I run the test suite with multiple options?
 
    Either of these examples will run the tests three times. Once with
    -fPIC, once with -fpic, and once with no additional flags.
-   
+
    This technique is particularly useful on multilibbed targets.
      _________________________________________________________________
-   
+
                            Platform-specific issues
-                                       
+
    Please read the [65]host/target specific installation notes, too.
-   
+
 Problems with exception handling on x86 platforms
 
    If you are using the GNU assembler (aka gas) on an x86 platform and
    exception handling is not working correctly, then odds are you're
    using a buggy assembler. Releases of binutils prior to 2.9 are known
    to assemble exception handling code incorrectly.
-   
+
    We recommend binutils-2.9.1 or newer. Some post-2.9.1 snapshots of
    binutils fix some subtle bugs, particularly on x86 and alpha. They are
    available at [66]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/. The
@@ -471,7 +471,7 @@ Problems with exception handling on x86 platforms
    than that, be aware that snapshots are in general untested and may not
    work (or even build). Use them at your own risk.
      _________________________________________________________________
-   
+
 Problems with invalid `asm' statements
 
    Previous releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2) did
@@ -483,7 +483,7 @@ Problems with invalid `asm' statements
    clobber registers that were destined to overlap operands; it could
    arguably be interpreted that it was correct to clobber an input
    operand to mark it as not holding a usable value after the asm.
-   
+
    For the general case, there is no way to tell whether a specified
    clobber is _intended_ to overlap with a specific (input) operand or is
    a program error, where the choice of actual register for operands
@@ -497,13 +497,13 @@ Problems with invalid `asm' statements
    Unfortunately, a lot of existing software, for example the [68]Linux
    kernel version 2.0.35 for the Intel x86, has constructs where input
    operands are marked as clobbered.
-   
+
    The manual now describes how to write constructs with operands that
    are modified by the construct, but not actually used. To write an asm
    which modifies an input operand but does not output anything usable,
    specify that operand as an _output operand_ outputting to an _unused
    dummy variable_.
-   
+
    In the following example for the x86 architecture (taken from the
    Linux 2.0.35 kernel -- include/asm-i386/delay.h), the register-class
    constraint "a" denotes a register class containing the single register
@@ -528,7 +528,7 @@ __delay (int loops)
    constructs, this obviousness-detection is not needed other than for
    reasons of compatibility with an existing code-base, and that code
    base can be corrected.
-   
+
    This corrected and clobber-less version, is _valid_ for GCC 2.95 as
    well as for previous versions of GCC and EGCS:
 extern __inline__ void
@@ -546,7 +546,7 @@ __delay (int loops)
    unused. Normally asm constructs with only unused output operands may
    be removed by gcc, unless marked volatile as above.
      _________________________________________________________________
-   
+
 Building Linux kernels
 
    The linux kernel violates certain aliasing rules specified in the
@@ -555,7 +555,7 @@ Building Linux kernels
    will produce malfunctioning kernels. To work around this problem, the
    flag -fno-strict-aliasing must be added to the CFLAGS variable in the
    main kernel Makefile.
-   
+
    If you try to build a 2.0.x kernel for Intel machines with any
    compiler other than GCC 2.7.2, then you are on your own. The 2.0.x
    kernels are to be built only with gcc 2.7.2. They use certain asm
@@ -564,7 +564,7 @@ Building Linux kernels
    be interested in this [69]patch which fixes some of the asm problems.
    You will also want to change asm constructs to [70]avoid clobbering
    their input operands.
-   
+
    If you installed a recent binutils/gas snapshot on your GNU/Linux
    system, you may not be able to build the kernel because objdump does
    not understand the "-k" switch. The solution for this problem is to
@@ -573,7 +573,7 @@ Building Linux kernels
    this program to decide if you have an old or a new binutils. Problems
    occur if you installed a new binutils but haven't removed encaps,
    because the Makefile thinks you have the old one.)
-   
+
    Finally, you may get errors with the X driver of the form
   _X11TransSocketUNIXConnect: Can't connect: errno = 111
 
@@ -582,59 +582,59 @@ Building Linux kernels
    is now broken since GCC optimizes more aggressively . The newer 2.1.x
    kernels already have a fix which should also work in 2.0.32.
      _________________________________________________________________
-   
+
 How do I compile X11 headers with g++
 
    When compiling X11 headers with a GCC 2.95 or newer, g++ will complain
    that types are missing. These headers assume that omitting the type
    means 'int'; this assumption is wrong for C++.
-   
+
    g++ accepts such (illegal) constructs with the option -fpermissive; it
    will assume that missing type is 'int' (as defined by the C89
    standard).
-   
+
    Since the upcoming C99 standard also obsoletes the implicit type
    assumptions, the X11 headers have to get fixed eventually.
      _________________________________________________________________
-   
+
 How to build a cross compiler
 
    Building cross compilers is a rather complex undertaking because they
    usually need additional software (cross assembler, cross linker,
    target libraries, target include files, etc).
-   
+
    We recommend reading the [71]crossgcc FAQ for information about
    building cross compilers.
-   
+
    If you have all the pieces available, then `make cross' should build a
    cross compiler. `make LANGUAGES="c c++" install' will install the
    cross compiler.
-   
+
    Note that if you're trying to build a cross compiler in a tree which
    includes binutils-2.8 in addition to GCC, then you're going to need to
    make a couple minor tweaks so that the cross assembler, linker and nm
    utilities will be found.
-   
+
    binutils-2.8 builds those files as gas.new, ld.new and nm.new; GCC
    looks for them using gas-new, ld-new and nm-new, so you may have to
    arrange for any symlinks which point to <file>.new to be changed to
    <file>-new.
      _________________________________________________________________
-   
+
                                Bugs and Non-Bugs
-                                       
+
    Unfortunately, improvements in tools that are widely used are sooner
    or later bound to break _something_. Sometimes, the code that breaks
    was wrong, and then that code should be fixed, even if it works for
    earlier versions of gcc or other compilers. The following problems
    with some releases of widely used packages have been identified:
-   
+
    There is a separate [72]list of well-known bugs describing known
    deficiencies. Naturally we'd like that list to be of zero length.
-   
+
    To report a bug, see [73]How to report bugs.
      _________________________________________________________________
-   
+
 FD_ZERO macro
 
    The FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses
@@ -653,18 +653,18 @@ FD_ZERO macro
                           : "memory"); \
     } while (0)
      _________________________________________________________________
-   
+
 Octave 2.0.13 does not compile
 
    Apparently Octave 2.0.13 uses some C++ features which have been
    obsoleted and thus fails to build with EGCS 1.1 and later. This
    [75]patch to Octave should fix this.
-   
+
    Octave 2.0.13.96, a test release, has been compiled without patches by
    egcs 1.1.2. It is available at
    [76]ftp://ftp.che.wisc.edu/pub/octave/test-releases/.
      _________________________________________________________________
-   
+
 Why can't I initialize a static variable with stdin?
 
    This has nothing to do with gcc, but people ask us about it a lot.
@@ -678,19 +678,19 @@ Why can't I initialize a static variable with stdin?
    limit on the number of open FILE objects. It is surprising for people
    used to traditional Unix C libraries, but it is permitted by the C
    standard.
-   
+
    This construct commonly occurs in code generated by old versions of
    lex or yacc. We suggest you try regenerating the parser with a current
    version of flex or bison, respectively. In your own code, the
    appropriate fix is to move the initialization to the beginning of
    main.
-   
+
    There is a common misconception that the GCC developers are
    responsible for GNU libc. These are in fact two entirely separate
    projects. The appropriate place to ask questions relating to GNU libc
    is [77]libc-alpha@sourceware.cygnus.com.
      _________________________________________________________________
-   
+
 Why can't I use #if here?
 
    Let me guess... you wrote code that looks something like this:
@@ -717,7 +717,7 @@ test.c:11: parse error before `#'
    to put #ifdef (or any other directive) inside the arguments of a
    macro. Your C library's string.h happens to define memcpy as a macro -
    this is perfectly legitimate. The code therefore will not compile.
-   
+
    We have two good reasons for not allowing directives inside macro
    arguments. First, it is not portable. It is "undefined behavior"
    according to the C standard; that means different compilers will do
@@ -729,7 +729,7 @@ test.c:11: parse error before `#'
    from the above example. A very few might do what you expected it to.
    We therefore feel it is most useful for GCC to reject this construct
    immediately so that it is found and fixed.
-   
+
    Second, it is extraordinarily difficult to implement the preprocessor
    such that it does what you would expect for every possible directive
    found inside a macro argument. The best example is perhaps
@@ -740,7 +740,7 @@ blah)
 
    which is impossible to implement in portable C without leaking memory.
    Allowing only a subset of directives would be confusing.
-   
+
    It is always possible to rewrite code which uses conditionals inside
    macros so that it doesn't. You could write the above example
 #ifdef PLATFORM1
@@ -752,33 +752,33 @@ blah)
    This is a bit more typing, but I personally think it's better style in
    addition to being more portable.
      _________________________________________________________________
-   
+
                                  Miscellaneous
-                                       
+
 Virtual memory exhausted error
 
    This error means your system ran out of memory; this can happen for
    large files, particularly when optimizing. If you're getting this
    error you should consider trying to simplify your files or reducing
    the optimization level.
-   
+
    Note that using -pedantic or -Wreturn-type can cause an explosion in
    the amount of memory needed for template-heavy C++ code, such as code
    that uses STL. Also note that -Wall includes -Wreturn-type, so if you
    use -Wall you will need to specify -Wno-return-type to turn it off.
      _________________________________________________________________
-   
+
 Snapshots, how, when, why
 
    We make snapshots of the GCC sources about once a week; there is no
    predetermined schedule. These snapshots are intended to give everyone
    access to work in progress. Any given snapshot may generate incorrect
    code or even fail to build.
-   
+
    If you plan on downloading and using snapshots, we highly recommend
    you subscribe to the GCC mailing lists. See [78]mailing lists on the
    main GCC page for instructions on how to subscribe.
-   
+
    When using the diff files to update from older snapshots to newer
    snapshots, make sure to use "-E" and "-p" arguments to patch so that
    empty files are deleted and full pathnames are provided to patch. If
@@ -787,7 +787,7 @@ Snapshots, how, when, why
    various other programs if you use diff files to update from one
    snapshot to the next.
      _________________________________________________________________
-   
+
 Friend Templates
 
    In order to make a specialization of a template function a friend of a
@@ -830,89 +830,89 @@ void bar(foo<T>) { /* ... */ }
    taken as a non-template function. Furthermore, in some cases, you may
    have to explicitly specify the template arguments, to remove
    ambiguity.
-   
+
    An error in the last public comment draft of the ANSI/ISO C++ Standard
    and the fact that previous releases of gcc would accept such friend
    declarations as template declarations has led people to believe that
    the forward declaration was not necessary, but, according to the final
    version of the Standard, it is.
      _________________________________________________________________
-   
+
 Where to find libg++
 
    Many folks have been asking where to find libg++ for GCC. First we
    should point out that few programs actually need libg++; most only
    need libstdc++/libio which are included in the GCC distribution.
-   
+
    If you do need libg++ you can get a libg++ release that works with GCC
    from [79]ftp://egcs.cygnus.com/pub/egcs/infrastructure/. Note that the
    2.8.2 snapshot pre-dates the 2.8.1.2 release.
      _________________________________________________________________
-   
+
 autoconf, bison, xgettext, automake, etc
 
    If you're using diffs up dated from one snapshot to the next, or if
    you're using the CVS repository, you may need several additional
    programs to build GCC.
-   
+
    These include, but are not necessarily limited to autoconf, automake,
    bison, and xgettext.
-   
+
    This is necessary because neither diff nor cvs keep timestamps
    correct. This causes problems for generated files as "make" may think
    those generated files are out of date and try to regenerate them.
-   
+
    An easy way to work around this problem is to use the gcc_update
    script in the contrib subdirectory of GCC, which handles this
    transparently without requiring installation of any additional tools.
    (Note: Up to and including GCC 2.95 this script was called egcs_update
    .)
-   
+
    When building from diffs or CVS or if you modified some sources, you
    may also need to obtain development versions of some GNU tools, as the
    production versions do not necessarily handle all features needed to
    rebuild GCC.
-   
+
    Autoconf is available from [80]http://sourceware.cygnus.com/autoconf/;
    have a look at [81]ftp://egcs.cygnus.com/pub/egcs/infrastructure/ for
    the other packages.
      _________________________________________________________________
-   
+
 Conflicts when using cvs update
 
    It is not uncommon to get CVS conflict messages for some generated
    files when updating your local sources from the CVS repository.
    Typically such conflicts occur with bison or autoconf generated files.
-   
+
    As long as you haven't been making modifications to the generated
    files or the generator files, it is safe to delete the offending file,
    then run cvs update again to get a new copy.
      _________________________________________________________________
-   
+
 Problems debugging GCC code
 
    On some systems GCC will produce dwarf debug records by default;
    however the gdb-4.16 release may not be able to read such debug
    records.
-   
+
    You can either use the argument "-gstabs" instead of "-g" or pick up a
    copy of gdb-4.17 to work around the problem.
      _________________________________________________________________
-   
+
 Using GCC with GNAT/Ada
 
    The GNU Ada front-end is not currently supported by GCC; however, it
    is possible to build the GNAT compiler with a little work.
-   
+
    First, retrieve the gnat-3.10p sources. The sources for the Ada front
    end and runtime all live in the "ada" subdirectory. Move that
    subdirectory to egcs/gcc/ada.
-   
+
    Second, apply the patch found in egcs/gcc/README.gnat.
-   
+
    Finally, rebuild per the GNAT build instructions.
      _________________________________________________________________
-   
+
 Using GCC with GNU Pascal
 
    The [82]GNU Pascal front-end does work with EGCS 1.1 It does not work
@@ -920,59 +920,59 @@ Using GCC with GNU Pascal
    can be found at
    [83]ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/.
      _________________________________________________________________
-   
+
 Using CVS to download snapshots
 
    It is possible to checkout specific snapshots with CVS or to check out
    the latest snapshot.
-   
+
    We use CVS tags to identify each snapshot we make. Snapshot tags have
    the form "egcs_ss_YYYYMMDD". In addition, the latest official snapshot
    always has the tag "gcc_latest_snapshot".
      _________________________________________________________________
-   
+
 Why can't I build a shared library?
 
    When building a shared library you may get an error message from the
    linker like `assert pure-text failed:' or `DP relative code in file'.
-   
+
    This kind of error occurs when you've failed to provide proper flags
    to gcc when linking the shared library.
-   
+
    You can get this error even if all the .o files for the shared library
    were compiled with the proper PIC option. When building a shared
    library, gcc will compile additional code to be included in the
    library. That additional code must also be compiled with the proper
    PIC option.
-   
+
    Adding the proper PIC option (-fpic or -fPIC) to the link line which
    creates the shared library will fix this problem on targets that
    support PIC in this manner. For example:
         gcc -c -fPIC myfile.c
         gcc -shared -o libmyfile.so -fPIC myfile.o
      _________________________________________________________________
-   
+
 How to work around too long C++ symbol names? (-fsquangle)
 
    If the standard assembler of your platform can't cope with the large
    symbol names that the default g++ name mangling mechanism produces,
    your best bet is to use GNU as, from the GNU binutils package.
-   
+
    Unfortunately, GNU as does not support all platforms supported by
    egcs, so you may have to use an experimental work-around: the
    -fsquangle option, that enables compression of symbol names.
-   
+
    Note that this option is still under development, and subject to
    change. Since it modifies the name mangling mechanism, you'll need to
    build libstdc++ and any other C++ libraries with this option enabled.
    Furthermore, if this option changes its behavior in the future, you'll
    have to rebuild them all again. :-(
-   
+
    This option can be enabled by default by initializing
    `flag_do_squangling' with `1' in `gcc/cp/decl2.c' (it is not
    initialized by default), then rebuilding egcs and any C++ libraries.
      _________________________________________________________________
-   
+
 When building from CVS sources, I see 'gperf: invalid option -- F', even with
 the most current version of gperf.
 
@@ -980,11 +980,11 @@ the most current version of gperf.
    is used when building egcs from CVS sources. You will need to obtain a
    patch for gperf and rebuild the program; this patch is available at
    [84]ftp://egcs.cygnus.com/pub/egcs/infrastructure/
-   
+
    Patches for other tools, particularly autoconf, may also be necessary
    if you're building from CVS sources. Please see the [85]FAQ entry
    regarding these tools to determine if anything else is needed.
-   
+
    These patched utilities should _only_ be required if you are building
    from CVS sources. For example, gperf is used to generate C code for a
    perfect hash function given an input file. Distributions of egcs
@@ -992,7 +992,7 @@ the most current version of gperf.
    provide only the gperf input file. So gperf should only be necessary
    if you are building anything obtained from CVS.
      _________________________________________________________________
-   
+
 When building C++, the linker says my constructors, destructors or virtual
 tables are undefined, but I defined them
 
@@ -1003,39 +1003,39 @@ tables are undefined, but I defined them
    constructors, the assignment operator, the destructor and the virtual
    table of a class in the translation unit that defines its first such
    non-inline method.
-   
+
    Therefore, if you fail to define this particular method, the linker
    may complain about the lack of definitions for apparently unrelated
    symbols. Unfortunately, in order to improve this error message, it
    might be necessary to change the linker, and this can't always be
    done.
-   
+
    The solution is to ensure that all virtual methods that are not pure
    are defined. Note that a destructor must be defined even if it is
    declared pure-virtual [class.dtor]/7.
      _________________________________________________________________
-   
+
 What is libstdc++-v3 and how can I use it with g++?
 
    From the [86]libstdc++-FAQ: "The EGCS Standard C++ Library v3, or
    libstdc++-2.90.x, is an ongoing project to implement the ISO 14882
    Standard C++ library as described in chapters 17 through 27 and annex
    D."
-   
+
    At the moment the libstdc++-v3 is no "drop in replacement" for GCC's
    libstdc++. The best way to use it is as follows:
     1. Build and install GCC
     2. Build and install libstdc++-v3
     3. Use compiler flags to use the new libstdc++
-       
+
    Please note that the libstdc++-v3 is not yet complete and should only
    be used by experienced programmers.
-   
+
    For more information please refer to the [87]libstdc++-v3 homepage
      _________________________________________________________________
-   
+
    [88]Return to the GCC home page
-   
+
    _Last modified: October 19, 1999_
 
 References
diff --git a/gnu/egcs/INSTALL/README b/gnu/egcs/INSTALL/README
index 8afbd068f4f..7c888f53a8c 100644
--- a/gnu/egcs/INSTALL/README
+++ b/gnu/egcs/INSTALL/README
@@ -1,9 +1,10 @@
-This directory has been obsoleted for egcs snapshots and CVS access.
+The installation instructions are no longer in this directory.  Instead
+they can be found in the "install" directory at the toplevel of the GCC
+distribution (ie gcc-2.95/install).  For HTML browsing start with
+install/index.html, for plaintext, start with install/INDEX.
 
-Instead check out the toplevel "wwwdocs" as a sibling of your egcs
-tree or read these files via the egcs web site
-http://www.gnu.org/software/gcc/
+Moving the installation instructions in this manner makes it significantly
+easier to share code between the distribution and the web pages.
 
-
-Copies of the relevant files will be copied into this directory for
-releases.
+This directory (INSTALL) will be completely removed in the next major
+GCC release.
diff --git a/gnu/egcs/configure b/gnu/egcs/configure
index cd6791b94e1..41b82fe8aef 100644
--- a/gnu/egcs/configure
+++ b/gnu/egcs/configure
@@ -86,7 +86,7 @@ subdirs=
 target_alias=NOTARGET
 target_makefile_frag=
 undefs=NOUNDEFS
-version="$Revision: 1.1.1.3 $"
+version="$Revision: 1.1.1.4 $"
 x11=default
 bindir='${exec_prefix}/bin'
 sbindir='${exec_prefix}/sbin'
diff --git a/gnu/egcs/etc/ChangeLog b/gnu/egcs/etc/ChangeLog
index 76a6628ab5a..64ae1b8629e 100644
--- a/gnu/egcs/etc/ChangeLog
+++ b/gnu/egcs/etc/ChangeLog
@@ -1,3 +1,7 @@
+2001-01-11  Bernd Schmidt  <bernds@redhat.co.uk>
+
+	* standards.texi, make-stds.texi: Update to FSF version of Jan 11.
+
 2000-05-18  Martin von Loewis  <loewis@informatik.hu-berlin.de>
 
 	* standards.texi, make-stds.texi: Update to FSF version of May 13.
diff --git a/gnu/egcs/etc/make-stds.texi b/gnu/egcs/etc/make-stds.texi
index b655ea58750..0f0e7d4d91e 100644
--- a/gnu/egcs/etc/make-stds.texi
+++ b/gnu/egcs/etc/make-stds.texi
@@ -249,9 +249,10 @@ Every Makefile should define the variable @code{INSTALL}, which is the
 basic command for installing a file into the system.
 
 Every Makefile should also define the variables @code{INSTALL_PROGRAM}
-and @code{INSTALL_DATA}.  (The default for each of these should be
-@code{$(INSTALL)}.)  Then it should use those variables as the commands
-for actual installation, for executables and nonexecutables
+and @code{INSTALL_DATA}.  (The default for @code{INSTALL_PROGRAM} should
+be @code{$(INSTALL)}; the default for @code{INSTALL_DATA} should be
+@code{$@{INSTALL@} -m 644}.)  Then it should use those variables as the
+commands for actual installation, for executables and nonexecutables
 respectively.  Use these variables as follows:
 
 @example
@@ -289,19 +290,21 @@ These two variables set the root for the installation.  All the other
 installation directories should be subdirectories of one of these two,
 and nothing should be directly installed into these two directories.
 
-@table @samp
+@table @code
 @item prefix
+@vindex prefix
 A prefix used in constructing the default values of the variables listed
 below.  The default value of @code{prefix} should be @file{/usr/local}.
 When building the complete GNU system, the prefix will be empty and
 @file{/usr} will be a symbolic link to @file{/}.
 (If you are using Autoconf, write it as @samp{@@prefix@@}.)
 
-Running @samp{make install} with a different value of @code{prefix}
-from the one used to build the program should @var{not} recompile
-the program.
+Running @samp{make install} with a different value of @code{prefix} from
+the one used to build the program should @emph{not} recompile the
+program.
 
 @item exec_prefix
+@vindex exec_prefix
 A prefix used in constructing the default values of some of the
 variables listed below.  The default value of @code{exec_prefix} should
 be @code{$(prefix)}.
@@ -312,20 +315,22 @@ machine-specific files (such as executables and subroutine libraries),
 while @code{$(prefix)} is used directly for other directories.
 
 Running @samp{make install} with a different value of @code{exec_prefix}
-from the one used to build the program should @var{not} recompile the
+from the one used to build the program should @emph{not} recompile the
 program.
 @end table
 
 Executable programs are installed in one of the following directories.
 
-@table @samp
+@table @code
 @item bindir
+@vindex bindir
 The directory for installing executable programs that users can run.
 This should normally be @file{/usr/local/bin}, but write it as
 @file{$(exec_prefix)/bin}.
 (If you are using Autoconf, write it as @samp{@@bindir@@}.)
 
 @item sbindir
+@vindex sbindir
 The directory for installing executable programs that can be run from
 the shell, but are only generally useful to system administrators.  This
 should normally be @file{/usr/local/sbin}, but write it as
@@ -333,6 +338,7 @@ should normally be @file{/usr/local/sbin}, but write it as
 (If you are using Autoconf, write it as @samp{@@sbindir@@}.)
 
 @item libexecdir
+@vindex libexecdir
 @comment This paragraph adjusted to avoid overfull hbox --roland 5jul94
 The directory for installing executable programs to be run by other
 programs rather than by users.  This directory should normally be
@@ -625,7 +631,8 @@ the installation commands.  @xref{Install Command Categories}.
 
 @item install-strip
 Like @code{install}, but strip the executable files while installing
-them.  In many cases, the definition of this target can be very simple:
+them.  In simple cases, this target can use the @code{install} target in
+a simple way:
 
 @smallexample
 install-strip:
@@ -633,6 +640,14 @@ install-strip:
                 install
 @end smallexample
 
+But if the package installs scripts as well as real executables, the
+@code{install-strip} target can't just refer to the @code{install}
+target; it has to strip the executables but not the scripts.
+
+@code{install-strip} should not strip the executables in the build
+directory which are being copied for installation.  It should only strip
+the copies that are installed.
+
 Normally we do not recommend stripping an executable unless you are sure
 the program has no bugs.  However, it can be reasonable to install a
 stripped executable for actual execution while saving the unstripped
diff --git a/gnu/egcs/etc/standards.texi b/gnu/egcs/etc/standards.texi
index 8970dad7dfd..8f515012e26 100644
--- a/gnu/egcs/etc/standards.texi
+++ b/gnu/egcs/etc/standards.texi
@@ -3,7 +3,7 @@
 @setfilename standards.info
 @settitle GNU Coding Standards
 @c This date is automagically updated when you save this file:
-@set lastupdate May 13, 2000
+@set lastupdate December  1, 2000
 @c %**end of header
 
 @ifinfo
@@ -17,6 +17,12 @@ END-INFO-DIR-ENTRY
 @c @setchapternewpage odd
 @setchapternewpage off
 
+@c Put everything in one index (arbitrarily chosen to be the concept index).
+@syncodeindex fn cp
+@syncodeindex ky cp
+@syncodeindex pg cp
+@syncodeindex vr cp
+
 @c This is used by a cross ref in make-stds.texi
 @set CODESTD  1
 @iftex
@@ -28,7 +34,7 @@ END-INFO-DIR-ENTRY
 
 @ifinfo
 GNU Coding Standards
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
+Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
 
 Permission is granted to make and distribute verbatim copies of
 this manual provided the copyright notice and this permission notice
@@ -59,7 +65,7 @@ by the Free Software Foundation.
 @page
 
 @vskip 0pt plus 1filll
-Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
 
 Permission is granted to make and distribute verbatim copies of
 this manual provided the copyright notice and this permission notice
@@ -92,6 +98,7 @@ Last updated @value{lastupdate}.
 * Documentation::           Documenting Programs
 * Managing Releases::       The Release Process
 * References::              References to Non-Free Software or Documentation
+* Index::
 @end menu
 
 @node Preface
@@ -106,7 +113,7 @@ even if you write in another programming language.  The rules often
 state reasons for writing in a certain way.
 
 Corrections or suggestions for this document should be sent to
-@email{gnu@@gnu.org}.  If you make a suggestion, please include a
+@email{bug-standards@@gnu.org}.  If you make a suggestion, please include a
 suggested new wording for it; our time is limited.  We prefer a context
 diff to the @file{standards.texi} or @file{make-stds.texi} files, but if
 you don't have those files, please mail your suggestion anyway.
@@ -114,8 +121,20 @@ you don't have those files, please mail your suggestion anyway.
 This release of the GNU Coding Standards was last updated
 @value{lastupdate}.
 
+@cindex where to obtain @code{standards.texi}
+@cindex downloading this manual
+If you did not obtain this file directly from the GNU project and
+recently, please check for a newer version.  You can ftp the GNU Coding
+Standards from any GNU FTP host in the directory
+@file{/pub/gnu/standards/}.  The GNU Coding Standards are available
+there in several different formats: @file{standards.text},
+@file{standards.texi}, @file{standards.info}, and @file{standards.dvi}.
+The GNU Coding Standards are also available on the GNU World Wide Web
+server: @uref{http://www.gnu.org/prep/standards_toc.html}.
+
 @node Legal Issues
 @chapter Keeping Free Software Free
+@cindex legal aspects
 
 This @value{CHAPTER} discusses how you can make sure that GNU software
 avoids legal difficulties, and other related issues.
@@ -128,6 +147,8 @@ avoids legal difficulties, and other related issues.
 
 @node Reading Non-Free Code
 @section Referring to Proprietary Programs
+@cindex proprietary programs
+@cindex avoiding proprietary code
 
 Don't in any circumstances refer to Unix source code for or during
 your work on GNU!  (Or to any other proprietary programs.)
@@ -161,6 +182,8 @@ to free memory, or use a new GNU facility such as obstacks.
 
 @node Contributions
 @section Accepting Contributions
+@cindex legal papers
+@cindex accepting contributions
 
 If the program you are working on is copyrighted by the Free Software
 Foundation, then when someone else sends you a piece of code to add to
@@ -205,6 +228,7 @@ released or not), please ask us for a copy.
 
 @node Trademarks
 @section Trademarks
+@cindex trademarks
 
 Please do not include any trademark acknowledgements in GNU software
 packages or documentation.
@@ -226,6 +250,7 @@ language.
 
 @node Design Advice
 @chapter General Program Design
+@cindex program design
 
 This @value{CHAPTER} discusses some of the issues you should take into
 account when designing your program.
@@ -238,15 +263,18 @@ account when designing your program.
 @c making  minor changes.   In 1990  ANSI then  re-adopted  ISO standard
 @c C. This version of C is known as either ANSI C or Standard C.
 
+@c A major revision of the C Standard appeared in 1999.
+
 @menu
 * Source Language::             Which languges to use.
 * Compatibility::               Compatibility with other implementations
 * Using Extensions::            Using non-standard features
-* Standard C::                  Using Standard (ANSI 1989) C features
+* Standard C::                  Using Standard C features
 @end menu
 
 @node Source Language
 @section Which Languages to Use
+@cindex programming languges
 
 When you want to use a language that gets compiled and runs at high
 speed, the best language to use is C.  Using another language is like
@@ -260,7 +288,7 @@ C has one other advantage over C++ and other compiled languages: more
 people know C, so more people will find it easy to read and modify the
 program if it is written in C.
 
-So in general it is much better to use use C, rather than the
+So in general it is much better to use C, rather than the
 comparable alternatives.
 
 But there are two exceptions to that conclusion:
@@ -283,6 +311,7 @@ for a language that is higher level than C.  Often much of the program
 is written in that language, too.  The Emacs editor pioneered this
 technique.
 
+@cindex GUILE
 The standard extensibility interpreter for GNU software is GUILE, which
 implements the language Scheme (an especially clean and simple dialect
 of Lisp).  @uref{http://www.gnu.org/software/guile/}.  We don't reject
@@ -292,23 +321,27 @@ the GNU system.
 
 @node Compatibility
 @section Compatibility with Other Implementations
+@cindex compatibility with C and @sc{posix} standards
+@cindex @sc{posix} compatibility
 
 With occasional exceptions, utility programs and libraries for GNU
 should be upward compatible with those in Berkeley Unix, and upward
-compatible with 1989 Standard C if 1989 Standard C specifies their
+compatible with Standard C if Standard C specifies their
 behavior, and upward compatible with @sc{posix} if @sc{posix} specifies
 their behavior.
 
 When these standards conflict, it is useful to offer compatibility
 modes for each of them.
 
-1989 Standard C and @sc{posix} prohibit many kinds of extensions.  Feel
+@cindex options for compatibility
+Standard C and @sc{posix} prohibit many kinds of extensions.  Feel
 free to make the extensions anyway, and include a @samp{--ansi},
 @samp{--posix}, or @samp{--compatible} option to turn them off.
 However, if the extension has a significant chance of breaking any real
 programs or scripts, then it is not really upward compatible.  So you
 should try to redesign its interface to make it upward compatible.
 
+@cindex @code{POSIXLY_CORRECT}, environment variable
 Many GNU programs suppress extensions that conflict with @sc{posix} if the
 environment variable @code{POSIXLY_CORRECT} is defined (even if it is
 defined with a null value).  Please make your program recognize this
@@ -325,6 +358,7 @@ there is any precedent for them.
 
 @node Using Extensions
 @section Using Non-standard Features
+@cindex non-standard extensions
 
 Many GNU facilities that already exist support a number of convenient
 extensions over the comparable Unix facilities.  Whether to use these
@@ -355,16 +389,21 @@ compiler, then no one can compile them without having them installed
 already.  That would be extremely troublesome in certain cases.
 
 @node Standard C
-@section 1989 Standard C and Pre-Standard C
+@section Standard C and Pre-Standard C
+@cindex @sc{ansi} C standard
 
 1989 Standard C is widespread enough now that it is ok to use its
 features in new programs.  There is one exception: do not ever use the
-``trigraph'' feature of 1989 Standard C.
+``trigraph'' feature of Standard C.
+
+1999 Standard C is not widespread yet, so please do not require its
+features in programs.  It is ok to use its features if they are present.
 
 However, it is easy to support pre-standard compilers in most programs,
 so if you know how to do that, feel free.  If a program you are
 maintaining has such support, you should try to keep it working.
 
+@cindex function prototypes
 To support pre-standard C, instead of writing function definitions in
 standard prototype form,
 
@@ -433,19 +472,24 @@ command line interface, and how libraries should behave.
 * Semantics::                   Writing robust programs
 * Libraries::                   Library behavior
 * Errors::                      Formatting error messages
-* User Interfaces::             Standards for command line interfaces
-* Option Table::                Table of long options.
+* User Interfaces::             Standards about interfaces generally
+* Graphical Interfaces::        Standards for graphical interfaces
+* Command-Line Interfaces::     Standards for command line interfaces
+* Option Table::                Table of long options
 * Memory Usage::                When and how to care about memory needs
+* File Usage::                  Which files to use, and where
 @end menu
 
 @node Semantics
 @section Writing Robust Programs
 
+@cindex arbitrary limits on data
 Avoid arbitrary limits on the length or number of @emph{any} data
 structure, including file names, lines, files, and symbols, by allocating
 all data structures dynamically.  In most Unix utilities, ``long lines
 are silently truncated''.  This is not acceptable in a GNU utility.
 
+@cindex @code{NUL} characters
 Utilities reading files should not drop NUL characters, or any other
 nonprinting characters @emph{including those with codes above 0177}.
 The only sensible exceptions would be utilities specifically intended
@@ -455,6 +499,7 @@ Whenever possible, try to make programs work properly with
 sequences of bytes that represent multibyte characters, using encodings
 such as UTF-8 and others.
 
+@cindex error messages
 Check every system call for an error return, unless you know you wish to
 ignore errors.  Include the system error text (from @code{perror} or
 equivalent) in @emph{every} error message resulting from a failing
@@ -462,6 +507,8 @@ system call, as well as the name of the file if any and the name of the
 utility.  Just ``cannot open foo.c'' or ``stat failed'' is not
 sufficient.
 
+@cindex @code{malloc} return value
+@cindex memory allocation failure
 Check every call to @code{malloc} or @code{realloc} to see if it
 returned zero.  Check @code{realloc} even if you are making the block
 smaller; in a system that rounds block sizes to a power of 2,
@@ -483,6 +530,7 @@ user), it is better to abort the command and return to the command
 reader loop.  This allows the user to kill other processes to free up
 virtual memory, and then try the command again.
 
+@cindex command-line arguments, decoding
 Use @code{getopt_long} to decode arguments, unless the argument syntax
 makes this unreasonable.
 
@@ -497,6 +545,7 @@ are less likely to work compatibly.  If you need to find all the files
 in a directory, use @code{readdir} or some other high-level interface.
 These are supported compatibly by GNU.
 
+@cindex signal handling
 The preferred signal handling facilities are the BSD variant of
 @code{signal}, and the @sc{posix} @code{sigaction} function; the
 alternative USG @code{signal} interface is an inferior design.
@@ -508,6 +557,7 @@ systems running GNU libc version 1, you should include
 behavior.  It is up to you whether to support systems where
 @code{signal} has only the USG behavior, or give up on them.
 
+@cindex impossible conditions
 In error checks that detect ``impossible'' conditions, just abort.
 There is usually no point in printing any message.  These checks
 indicate the existence of bugs.  Whoever wants to fix the bugs will have
@@ -522,14 +572,15 @@ bits (0 through 255).  A single run of the program might have 256
 errors; if you try to return 256 as the exit status, the parent process
 will see 0 as the status, and it will appear that the program succeeded.
 
+@cindex temporary files
+@cindex @code{TMPDIR} environment variable
 If you make temporary files, check the @code{TMPDIR} environment
 variable; if that variable is defined, use the specified directory
 instead of @file{/tmp}.
 
 In addition, be aware that there is a possible security problem when
-creating temporary files in directories world-writable directories.  In
-C, you can avoid this problem by creating temporary files in this
-manner:
+creating temporary files in world-writable directories.  In C, you can
+avoid this problem by creating temporary files in this manner:
 
 @example
 fd = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0600);
@@ -542,6 +593,7 @@ In bash, use @code{set -C} to avoid this problem.
 
 @node Libraries
 @section Library Behavior
+@cindex libraries
 
 Try to make library functions reentrant.  If they need to do dynamic
 storage allocation, at least try to avoid any nonreentrancy aside from
@@ -561,16 +613,18 @@ together, so that no reasonable program could use one without the
 other; then they can both go in the same file.
 
 External symbols that are not documented entry points for the user
-should have names beginning with @samp{_}.  They should also contain
-the chosen name prefix for the library, to prevent collisions with
-other libraries.  These can go in the same files with user entry
-points if you like.
+should have names beginning with @samp{_}.  The @samp{_} should be
+followed by the chosen name prefix for the library, to prevent
+collisions with other libraries.  These can go in the same files with
+user entry points if you like.
 
 Static functions and variables can be used as you like and need not
 fit any naming convention.
 
 @node Errors
 @section Formatting Error Messages
+@cindex formatting error messages
+@cindex error messages, formatting
 
 Error messages from compilers should look like this:
 
@@ -630,8 +684,10 @@ usage messages, should start with a capital letter.  But they should not
 end with a period.
 
 @node User Interfaces
-@section Standards for Command Line Interfaces
+@section Standards for Interfaces Generally
 
+@cindex program name and its behavior
+@cindex behavior, dependent on program's name
 Please don't make the behavior of a utility depend on the name used
 to invoke it.  It is useful sometimes to make a link to a utility
 with a different name, and that should not change what it does.
@@ -639,6 +695,7 @@ with a different name, and that should not change what it does.
 Instead, use a run time option or a compilation switch or both
 to select among the alternate behaviors.
 
+@cindex output device and program's behavior
 Likewise, please don't make the behavior of the program depend on the
 type of output device it is used with.  Device independence is an
 important principle of the system's design; do not compromise it merely
@@ -660,6 +717,34 @@ output device type.  For example, we provide a @code{dir} program much
 like @code{ls} except that its default output format is always
 multi-column format.
 
+@node Graphical Interfaces
+@section Standards for Graphical Interfaces
+@cindex graphical user interface
+
+@cindex gtk
+When you write a program that provides a graphical user interface,
+please make it work with X Windows and the GTK toolkit unless the
+functionality specifically requires some alternative (for example,
+``displaying jpeg images while in console mode'').
+
+In addition, please provide a command-line interface to control the
+functionality.  (In many cases, the graphical user interface can be a
+separate program which invokes the command-line program.)  This is
+so that the same jobs can be done from scripts.
+
+@cindex corba
+@cindex gnome
+Please also consider providing a CORBA interface (for use from GNOME), a
+library interface (for use from C), and perhaps a keyboard-driven
+console interface (for use by users from console mode).  Once you are
+doing the work to provide the functionality and the graphical interface,
+these won't be much extra work.
+
+@node Command-Line Interfaces
+@section Standards for Command Line Interfaces
+@cindex command-line interface
+
+@findex getopt
 It is a good idea to follow the @sc{posix} guidelines for the
 command-line options of a program.  The easiest way to do this is to use
 @code{getopt} to parse them.  Note that the GNU version of @code{getopt}
@@ -667,6 +752,7 @@ will normally permit options anywhere among the arguments unless the
 special argument @samp{--} is used.  This is not what @sc{posix}
 specifies; it is a GNU extension.
 
+@cindex long-named options
 Please define long-named options that are equivalent to the
 single-letter Unix-style options.  We hope to make GNU more user
 friendly this way.  This is easy to do with the GNU function
@@ -686,16 +772,20 @@ file name as an ordinary argument for compatibility, try to provide an
 option as another way to specify it.  This will lead to more consistency
 among GNU utilities, and fewer idiosyncracies for users to remember.
 
+@cindex standard command-line options
 All programs should support two standard options: @samp{--version}
 and @samp{--help}.
 
 @table @code
+@cindex @samp{--version} option
 @item --version
 This option should direct the program to print information about its name,
 version, origin and legal status, all on standard output, and then exit
 successfully.  Other options and arguments should be ignored once this
 is seen, and the program should not perform its normal function.
 
+@cindex canonical name of a program
+@cindex program's canonical name
 The first line is meant to be easy for a program to parse; the version
 number proper starts after the last space.  In addition, it contains
 the canonical name for this program, in this format:
@@ -768,12 +858,15 @@ versions' changes.  You don't have to mention the name of the program in
 these notices, if that is inconvenient, since it appeared in the first
 line.
 
+@cindex @samp{--help} option
 @item --help
 This option should output brief documentation for how to invoke the
 program, on standard output, then exit successfully.  Other options and
 arguments should be ignored once this is seen, and the program should
 not perform its normal function.
 
+@cindex address for bug reports
+@cindex bug reports
 Near the end of the @samp{--help} option's output there should be a line
 that says where to mail bug reports.  It should have this format:
 
@@ -784,11 +877,13 @@ Report bugs to @var{mailing-address}.
 
 @node Option Table
 @section Table of Long Options
+@cindex long option names
+@cindex table of long options
 
 Here is a table of long options used by GNU programs.  It is surely
 incomplete, but we aim to list all the options that a new program might
 want to be compatible with.  If you use names not already in the table,
-please send @email{gnu@@gnu.org} a list of them, with their
+please send @email{bug-standards@@gnu.org} a list of them, with their
 meanings, so we can update the table.
 
 @c Please leave newlines between items in this table; it's much easier
@@ -1901,8 +1996,9 @@ Print the version number.
 
 @node Memory Usage
 @section Memory Usage
+@cindex memory usage
 
-If it typically uses just a few meg of memory, don't bother making any
+If a program typically uses just a few meg of memory, don't bother making any
 effort to reduce memory usage.  For example, if it is impractical for
 other reasons to operate on files more than a few meg long, it is
 reasonable to read entire input files into core to operate on them.
@@ -1918,6 +2014,23 @@ files that are bigger than will fit in core all at once.
 If your program creates complicated data structures, just make them in
 core and give a fatal error if @code{malloc} returns zero.
 
+@node File Usage
+@section File Usage
+@cindex file usage
+
+Programs should be prepared to operate when @file{/usr} and @file{/etc}
+are read-only file systems.  Thus, if the program manages log files,
+lock files, backup files, score files, or any other files which are
+modified for internal purposes, these files should not be stored in
+@file{/usr} or @file{/etc}.
+
+There are two exceptions.  @file{/etc} is used to store system
+configuration information; it is reasonable for a program to modify
+files in @file{/etc} when its job is to update the system configuration.
+Also, if the user explicitly asks to modify one file in a directory, it
+is reasonable for the program to store other files in the same
+directory.
+
 @node Writing C
 @chapter Making The Best Use of C
 
@@ -1938,7 +2051,10 @@ when writing GNU software.
 
 @node Formatting
 @section Formatting Your Source Code
+@cindex formatting source code
 
+@cindex open brace
+@cindex braces, in C source
 It is important to put the open-brace that starts the body of a C
 function in column zero, and avoid putting any other open-brace or
 open-parenthesis or open-bracket in column zero.  Several tools look
@@ -1982,7 +2098,15 @@ lots_of_args (int an_integer, long a_long, short a_short,
 @end example
 
 The rest of this section gives our recommendations for other aspects of
-C formatting style.  We don't think of them as requirements, because it
+C formatting style, which is also the default style of the @code{indent}
+program in version 1.2 and newer.  It corresponds to the options
+
+@smallexample
+-nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2
+-ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob
+@end smallexample
+
+We don't think of these recommendations as requirements, because it
 causes no problems for users if two different programs have different
 formatting styles.
 
@@ -2007,12 +2131,14 @@ else
   @}
 @end example
 
+@cindex spaces before open-paren
 We find it easier to read a program when it has spaces before the
 open-parentheses and after the commas.  Especially after the commas.
 
 When you split an expression into multiple lines, split it
 before an operator, not after one.  Here is the right way:
 
+@cindex expressions, splitting
 @example
 if (foo_this_is_long && bar > win (x, y, z)
     && remaining_condition)
@@ -2062,6 +2188,8 @@ do
 while (a > 0);
 @end example
 
+@cindex formfeed
+@cindex control-L
 Please use formfeed characters (control-L) to divide the program into
 pages at logical places (but not within a function).  It does not matter
 just how long the pages are, since they do not have to fit on a printed
@@ -2069,6 +2197,7 @@ page.  The formfeeds should appear alone on lines by themselves.
 
 @node Comments
 @section Commenting Your Work
+@cindex commenting
 
 Every program should start with a comment saying briefly what it is for.
 Example: @samp{fmt - filter for simple filling of text}.
@@ -2120,6 +2249,8 @@ There should be a comment on each static variable as well, like this:
 int truncate_lines;
 @end example
 
+@cindex conditionals, comments for
+@cindex @code{#endif}, commenting
 Every @samp{#endif} should have a comment, except in the case of short
 conditionals (just a few lines) that are not nested.  The comment should
 state the condition of the conditional that is ending, @emph{including
@@ -2161,10 +2292,17 @@ but, by contrast, write the comments this way for a @samp{#ifndef}:
 
 @node Syntactic Conventions
 @section Clean Use of C Constructs
+@cindex syntactic conventions
 
-Please explicitly declare all arguments to functions.
-Don't omit them just because they are @code{int}s.
+@cindex implicit @code{int}
+@cindex function argument, declaring
+Please explicitly declare the types of all objects.  For example, you
+should explicitly declare all arguments to functions, and you should
+declare functions to return @code{int} rather than omitting the
+@code{int}.
 
+@cindex compiler warnings
+@cindex @samp{-Wall} compiler option
 Some programmers like to use the GCC @samp{-Wall} option, and change the
 code whenever it issues a warning.  If you want to do this, then do.
 Other programmers prefer not to use @samp{-Wall}, because it gives
@@ -2178,6 +2316,7 @@ source file should all go in one place near the beginning of the file
 should go in a header file.  Don't put @code{extern} declarations inside
 functions.
 
+@cindex temporary variables
 It used to be common practice to use the same local variables (with
 names like @code{tem}) over and over for different values within one
 function.  Instead of doing this, it is better declare a separate local
@@ -2189,6 +2328,7 @@ all its uses.  This makes the program even cleaner.
 
 Don't use local variables or parameters that shadow global identifiers.
 
+@cindex multiple variables in a line
 Don't declare multiple variables in one declaration that spans lines.
 Start a new declaration on each line, instead.  For example, instead
 of this:
@@ -2289,6 +2429,7 @@ if (foo == 0)
   fatal ("virtual memory exhausted");
 @end example
 
+@pindex lint
 Don't make the program ugly to placate @code{lint}.  Please don't insert any
 casts to @code{void}.  Zero without a cast is perfectly fine as a null
 pointer constant, except when calling a varargs function.
@@ -2296,6 +2437,7 @@ pointer constant, except when calling a varargs function.
 @node Names
 @section Naming Variables and Functions
 
+@cindex names of variables and functions
 The names of global variables and functions in a program serve as
 comments of a sort.  So don't choose terse names---instead, look for
 names that give useful information about the meaning of the variable or
@@ -2333,30 +2475,41 @@ When you want to define names with constant integer values, use
 @code{enum} rather than @samp{#define}.  GDB knows about enumeration
 constants.
 
-Use file names of 14 characters or less, to avoid creating gratuitous
-problems on older System V systems.  You can use the program
-@code{doschk} to test for this.  @code{doschk} also tests for potential
-name conflicts if the files were loaded onto an MS-DOS file
-system---something you may or may not care about.
+@cindex file-name limitations
+@pindex doschk
+You might want to make sure that none of the file names would conflict
+the files were loaded onto an MS-DOS file system which shortens the
+names.  You can use the program @code{doschk} to test for this.
+
+Some GNU programs were designed to limit themselves to file names of 14
+characters or less, to avoid file name conflicts if they are read into
+older System V systems.  Please preserve this feature in the existing
+GNU programs that have it, but there is no need to do this in new GNU
+programs.  @code{doschk} also reports file names longer than 14
+characters.
 
 @node System Portability
 @section Portability between System Types
+@cindex portability, between system types
 
 In the Unix world, ``portability'' refers to porting to different Unix
 versions.  For a GNU program, this kind of portability is desirable, but
 not paramount.
 
 The primary purpose of GNU software is to run on top of the GNU kernel,
-compiled with the GNU C compiler, on various types of @sc{cpu}.  The
-amount and kinds of variation among GNU systems on different @sc{cpu}s
-will be comparable to the variation among Linux-based GNU systems or
-among BSD systems today.  So the kinds of portability that are absolutely
-necessary are quite limited.
-
-But many users do run GNU software on non-GNU Unix or Unix-like systems.
-So supporting a variety of Unix-like systems is desirable, although not
-paramount.
-
+compiled with the GNU C compiler, on various types of @sc{cpu}.  So the
+kinds of portability that are absolutely necessary are quite limited.
+But it is important to support Linux-based GNU systems, since they
+are the form of GNU that is popular.
+
+Beyond that, it is good to support the other free operating systems
+(*BSD), and it is nice to support other Unix-like systems if you want
+to.  Supporting a variety of Unix-like systems is desirable, although
+not paramount.  It is usually not too hard, so you may as well do it.
+But you don't have to consider it an obligation, if it does turn out to
+be hard.
+
+@pindex autoconf
 The easiest way to achieve portability to most Unix-like systems is to
 use Autoconf.  It's unlikely that your program needs to know more
 information about the host platform than Autoconf can provide, simply
@@ -2366,6 +2519,7 @@ written.
 Avoid using the format of semi-internal data bases (e.g., directories)
 when there is a higher-level alternative (@code{readdir}).
 
+@cindex non-@sc{posix} systems, and portability
 As for systems that are not like Unix, such as MSDOS, Windows, the
 Macintosh, VMS, and MVS, supporting them is often a lot of work.  When
 that is the case, it is better to spend your time adding features that
@@ -2387,6 +2541,8 @@ to move your code into other GNU programs.
 @node CPU Portability
 @section Portability between @sc{cpu}s
 
+@cindex data types, and portability
+@cindex portability, and data types
 Even GNU systems will differ because of differences among @sc{cpu}
 types---for example, difference in byte ordering and alignment
 requirements.  It is absolutely essential to handle these differences.
@@ -2394,6 +2550,25 @@ However, don't make any effort to cater to the possibility that an
 @code{int} will be less than 32 bits.  We don't support 16-bit machines
 in GNU.
 
+Similarly, don't make any effort to cater to the possibility that
+@code{long} will be smaller than predefined types like @code{size_t}.
+For example, the following code is ok:
+
+@example
+printf ("size = %lu\n", (unsigned long) sizeof array);
+printf ("diff = %ld\n", (long) (pointer2 - pointer1));
+@end example
+
+1989 Standard C requires this to work, and we know of only one
+counterexample: 64-bit programs on Microsoft Windows IA-64.  We will
+leave it to those who want to port GNU programs to that environment
+to figure out how to do it.
+
+Predefined file-size types like @code{off_t} are an exception: they are
+longer than @code{long} on many platforms, so code like the above won't
+work with them.  One way to print an @code{off_t} value portably is to
+print its digits yourself, one by one.
+
 Don't assume that the address of an @code{int} object is also the
 address of its least-significant byte.  This is false on big-endian
 machines.  Thus, don't make the following mistake:
@@ -2408,7 +2583,7 @@ while ((c = getchar()) != EOF)
 When calling functions, you need not worry about the difference between
 pointers of various types, or between pointers and integers.  On most
 machines, there's no difference anyway.  As for the few machines where
-there is a difference, all of them support 1989 Standard C, so you can
+there is a difference, all of them support Standard C prototypes, so you can
 use prototypes (perhaps conditionalized to be active only in Standard C)
 to make the code work on those systems.
 
@@ -2433,10 +2608,11 @@ the widest possible kind of argument; it is much simpler than any
 ``correct'' alternative.  Be sure @emph{not} to use a prototype for such
 functions.
 
-If you have decided to use 1989 Standard C, then you can instead define
+If you have decided to use Standard C, then you can instead define
 @code{error} using @file{stdarg.h}, and pass the arguments along to
 @code{vfprintf}.
 
+@cindex casting pointers to integers
 Avoid casting pointers to integers if you can.  Such casts greatly
 reduce portability, and in most programs they are easy to avoid.  In the
 cases where casting pointers to integers is essential---such as, a Lisp
@@ -2448,8 +2624,10 @@ from zero.
 
 @node System Functions
 @section Calling System Functions
+@cindex library functions, and portability
+@cindex portability, and library functions
 
-C implementations differ substantially.  1989 Standard C reduces but does
+C implementations differ substantially.  Standard C reduces but does
 not eliminate the incompatibilities; meanwhile, many GNU packages still
 support pre-standard compilers because this is not hard to do.  This
 chapter gives recommendations for how to use the more-or-less standard C
@@ -2468,6 +2646,7 @@ Be aware that @code{vfprintf} is not always available.
 terminate either by calling @code{exit} or by returning the integer
 status code; make sure it cannot ever return an undefined value.
 
+@cindex declaration for system functions
 @item
 Don't declare system functions explicitly.
 
@@ -2506,6 +2685,7 @@ exceptional systems (mostly 64-bit machines), you can use
 @code{realloc}---or put these declarations in configuration files
 specific to those systems.
 
+@cindex string library functions
 @item
 The string functions require special treatment.  Some Unix systems have
 a header file @file{string.h}; others have @file{strings.h}.  Neither
@@ -2572,7 +2752,9 @@ One way to get them properly defined is to use Autoconf.
 
 @node Internationalization
 @section Internationalization
+@cindex internationalization
 
+@pindex gettext
 GNU has a library called GNU gettext that makes it easy to translate the
 messages in a program into various languages.  You should use this
 library in every program.  Use English for the messages as they appear
@@ -2599,6 +2781,7 @@ translations for this package from the translations for other packages.
 Normally, the text domain name should be the same as the name of the
 package---for example, @samp{fileutils} for the GNU file utilities.
 
+@cindex message text, and internationalization
 To enable gettext to work well, avoid writing code that makes
 assumptions about the structure of words or sentences.  When you want
 the precise text of a sentence to vary depending on the data, use two or
@@ -2670,6 +2853,7 @@ printf (f->tried_implicit
 
 @node Mmap
 @section Mmap
+@findex mmap
 
 Don't assume that @code{mmap} either works on all files or fails
 for all files.  It may work on some files and fail on others.
@@ -2686,11 +2870,19 @@ all these kinds of files.
 
 @node Documentation
 @chapter Documenting Programs
+@cindex documentation
+
+A GNU program should ideally come with full free documentation, adequate
+for both reference and tutorial purposes.  If the package can be
+programmed or extended, the documentation should cover programming or
+extending it, as well as just using it.
 
 @menu
 * GNU Manuals::                 Writing proper manuals.
+* Doc Strings and Manuals::     Compiling doc strings doesn't make a manual.
 * Manual Structure Details::    Specific structure conventions.
 * License for Manuals::         Writing the distribution terms for a manual.
+* Manual Credits::              Giving credit to documentation contributors.
 * NEWS File::                   NEWS files supplement manuals.
 * Change Logs::                 Recording Changes
 * Man Pages::                   Man pages are secondary.
@@ -2701,13 +2893,18 @@ all these kinds of files.
 @node GNU Manuals
 @section GNU Manuals
 
-The preferred way to document part of the GNU system is to write a
-manual in the Texinfo formatting language.  This makes it possible to
-produce a good quality formatted book, using @TeX{}, and to generate an
-Info file.  It is also possible to generate HTML output from Texinfo
-source.  See the Texinfo manual, either the hardcopy, or the on-line
-version available through @code{info} or the Emacs Info subsystem
-(@kbd{C-h i}).
+The preferred document format for the GNU system is the Texinfo
+formatting language.  Every GNU package should (ideally) have
+documentation in Texinfo both for reference and for learners.  Texinfo
+makes it possible to produce a good quality formatted book, using
+@TeX{}, and to generate an Info file.  It is also possible to generate
+HTML output from Texinfo source.  See the Texinfo manual, either the
+hardcopy, or the on-line version available through @code{info} or the
+Emacs Info subsystem (@kbd{C-h i}).
+
+Nowadays some other formats such as Docbook and Sgmltexi can be
+converted automatically into Texinfo.  It is ok to produce the Texinfo
+documentation by conversion this way, as long as it gives good results.
 
 Programmers often find it most natural to structure the documentation
 following the structure of the implementation, which they know.  But
@@ -2736,9 +2933,9 @@ have one manual for ``comparison of files'' which covers both of those
 programs, as well as @code{cmp}.  By documenting these programs
 together, we can make the whole subject clearer.
 
-The manual which discusses a program should document all of the
-program's command-line options and all of its commands.  It should give
-examples of their use.  But don't organize the manual as a list of
+The manual which discusses a program should certainly document all of
+the program's command-line options and all of its commands.  It should
+give examples of their use.  But don't organize the manual as a list of
 features.  Instead, organize it logically, by subtopics.  Address the
 questions that a user will ask when thinking about the job that the
 program does.
@@ -2763,10 +2960,19 @@ are purely tutorial and cover the basics of the subject.  These provide
 the framework for a beginner to understand the rest of the manual.  The
 Bison manual provides a good example of how to do this.
 
+To serve as a reference, a manual should have an Index that list all the
+functions, variables, options, and important concepts that are part of
+the program.  One combined Index should do for a short manual, but
+sometimes for a complex package it is better to use multiple indices.
+The Texinfo manual includes advice on preparing good index entries, see
+@ref{Index Entries, , Making Index Entries, texinfo, The GNU Texinfo
+Manual}, and see @ref{Indexing Commands, , Defining the Entries of an
+Index, texinfo, The GNU Texinfo manual}.
+
 Don't use Unix man pages as a model for how to write GNU documentation;
 most of them are terse, badly structured, and give inadequate
-explanation of the underlying concepts.  (There are, of course
-exceptions.)  Also Unix man pages use a particular format which is
+explanation of the underlying concepts.  (There are, of course, some
+exceptions.)  Also, Unix man pages use a particular format which is
 different from what we use in GNU manuals.
 
 Please include an email address in the manual for where to report
@@ -2778,10 +2984,38 @@ documentation; use ``file name'' (two words) instead.  We use the term
 
 Please do not use the term ``illegal'' to refer to erroneous input to a
 computer program.  Please use ``invalid'' for this, and reserve the term
-``illegal'' for violations of law.
+``illegal'' for activities punishable by law.
+
+@node Doc Strings and Manuals
+@section Doc Strings and Manuals
+
+Some programming systems, such as Emacs, provide a documentation string
+for each function, command or variable.  You may be tempted to write a
+reference manual by compiling the documentation strings and writing a
+little additional text to go around them---but you must not do it.  That
+approach is a fundamental mistake.  The text of well-written
+documentation strings will be entirely wrong for a manual.
+
+A documentation string needs to stand alone---when it appears on the
+screen, there will be no other text to introduce or explain it.
+Meanwhile, it can be rather informal in style.
+
+The text describing a function or variable in a manual must not stand
+alone; it appears in the context of a section or subsection.  Other text
+at the beginning of the section should explain some of the concepts, and
+should often make some general points that apply to several functions or
+variables.  The previous descriptions of functions and variables in the
+section will also have given information about the topic.  A description
+written to stand alone would repeat some of that information; this
+redundance looks bad.  Meanwhile, the informality that is acceptable in
+a documentation string is totally unacceptable in a manual.
+
+The only good way to use documentation strings in writing a good manual
+is to use them as a source of information for writing good text.
 
 @node Manual Structure Details
 @section Manual Structure Details
+@cindex manual structure
 
 The title page of the manual should state the version of the programs or
 packages documented in the manual.  The Top node of the manual should
@@ -2801,26 +3035,44 @@ Alternatively, put a menu item in some menu whose item name fits one of
 the above patterns.  This identifies the node which that item points to
 as the node for this purpose, regardless of the node's actual name.
 
-There will be automatic features for specifying a program name and
-quickly reading just this part of its manual.
+The @samp{--usage} feature of the Info reader looks for such a node
+or menu item in order to find the relevant text, so it is essential
+for every Texinfo file to have one.
 
 If one manual describes several programs, it should have such a node for
-each program described.
+each program described in the manual.
 
 @node License for Manuals
 @section License for Manuals
+@cindex license for manuals
 
-If the manual contains a copy of the GNU GPL or GNU LGPL, or if it
-contains chapters that make political or personal statements, please
-copy the distribution terms of the GNU Emacs Manual, and adapt it by
-modifying appropriately the list of special chapters that may not be
-modified or deleted.
+Please use the GNU Free Documentation License for all GNU manuals that
+are more than a few pages long.  Likewise for a collection of short
+documents---you only need one copy of the GNU FDL for the whole
+collection.  For a single short document, you can use a very permissive
+non-copyleft license, to avoid taking up space with a long license.
 
-If the manual does not contain any such chapters, then imitate the
-simpler distribution terms of the Texinfo manual.
+See @uref{http://www.gnu.org/copyleft/fdl-howto.html} for more explanation
+of how to employ the GFDL.
+
+Note that it is not obligatory to include a copy of the GNU GPL or GNU
+LGPL in a manual whose license is neither the GPL nor the LGPL.  It can
+be a good idea to include the program's license in a large manual; in a
+short manual, whose size would be increased considerably by including
+the program's license, it is probably better not to include it.
+
+@node Manual Credits
+@section Manual Credits
+@cindex credits for manuals
+
+Please credit the principal human writers of the manual as the authors,
+on the title page of the manual.  If a company sponsored the work, thank
+the company in a suitable place in the manual, but do not cite the
+company as an author.
 
 @node NEWS File
 @section The NEWS File
+@cindex @file{NEWS} file
 
 In addition to its manual, the package should have a file named
 @file{NEWS} which contains a list of user-visible changes worth
@@ -2835,6 +3087,7 @@ user to that file.
 
 @node Change Logs
 @section Change Logs
+@cindex change logs
 
 Keep a change log to describe all the changes made to program source
 files.  The purpose of this is so that people investigating bugs in the
@@ -2849,6 +3102,7 @@ history of how the conflicting concepts arose and who they came from.
 * Style of Change Logs::        
 * Simple Changes::              
 * Conditional Changes::         
+* Indicating the Part Changed::
 @end menu
 
 @node Change Log Concepts
@@ -2889,10 +3143,16 @@ Then describe the changes you made to that function or variable.
 
 @node Style of Change Logs
 @subsection Style of Change Logs
+@cindex change logs, style
 
-Here are some examples of change log entries:
+Here are some simple examples of change log entries, starting with the
+header line that says who made the change and when, followed by
+descriptions of specific changes.  (These examples are drawn from Emacs
+and GCC.)
 
 @example
+1998-08-17  Richard Stallman  <rms@@gnu.org>
+
 * register.el (insert-register): Return nil.
 (jump-to-register): Likewise.
 
@@ -2923,6 +3183,15 @@ entries represent parts of the same change, so that they work together,
 then don't put blank lines between them.  Then you can omit the file
 name and the asterisk when successive entries are in the same file.
 
+Break long lists of function names by closing continued lines with
+@samp{)}, rather than @samp{,}, and opening the continuation with
+@samp{(} as in this example:
+
+@example
+* keyboard.c (menu_bar_items, tool_bar_items)
+(Fexecute_extended_command): Deal with `keymap' property.
+@end example
+
 @node Simple Changes
 @subsection Simple Changes
 
@@ -2930,9 +3199,10 @@ Certain simple kinds of changes don't need much detail in the change
 log.
 
 When you change the calling sequence of a function in a simple fashion,
-and you change all the callers of the function, there is no need to make
-individual entries for all the callers that you changed.  Just write in
-the entry for the function being called, ``All callers changed.''
+and you change all the callers of the function to use the new calling
+sequence, there is no need to make individual entries for all the
+callers that you changed.  Just write in the entry for the function
+being called, ``All callers changed''---like this:
 
 @example
 * keyboard.c (Fcommand_execute): New arg SPECIAL.
@@ -2952,6 +3222,8 @@ documentation says with the way the program actually works.
 
 @node Conditional Changes
 @subsection Conditional Changes
+@cindex conditional changes, and change logs
+@cindex change logs, conditional changes
 
 C programs often contain compile-time @code{#if} conditionals.  Many
 changes are conditional; sometimes you add a new definition which is
@@ -2991,8 +3263,23 @@ a certain macro is @emph{not} defined:
 (gethostname) [!HAVE_SOCKETS]: Replace with winsock version.
 @end example
 
+@node Indicating the Part Changed
+@subsection Indicating the Part Changed
+
+Indicate the part of a function which changed by using angle brackets
+enclosing an indication of what the changed part does.  Here is an entry
+for a change in the part of the function @code{sh-while-getopts} that
+deals with @code{sh} commands:
+
+@example
+* progmodes/sh-script.el (sh-while-getopts) <sh>: Handle case that
+user-specified option string is empty.
+@end example
+
+
 @node Man Pages
 @section Man Pages
+@cindex man pages
 
 In the GNU project, man pages are secondary.  It is not necessary or
 expected for every GNU program to have a man page, but some of them do.
@@ -3039,6 +3326,7 @@ with the FSF about the individual case.
 
 @node Managing Releases
 @chapter The Release Process
+@cindex releasing
 
 Making a release is more than just bundling up your source files in a
 tar file and putting it up for FTP.  You should set up your software so
@@ -3056,7 +3344,9 @@ all GNU software.
 
 @node Configuration
 @section How Configuration Should Work
+@cindex program configuration
 
+@pindex configure
 Each GNU distribution should come with a shell script named
 @code{configure}.  This script is given arguments which describe the
 kind of machine and system you want to compile the program for.
@@ -3124,13 +3414,14 @@ The @code{configure} script needs to be able to decode all plausible
 alternatives for how to describe a machine.  Thus, @samp{sun3-sunos4.1}
 would be a valid alias.  For many programs, @samp{vax-dec-ultrix} would
 be an alias for @samp{vax-dec-bsd}, simply because the differences
-between Ultrix and @sc{BSD} are rarely noticeable, but a few programs
+between Ultrix and @sc{bsd} are rarely noticeable, but a few programs
 might need to distinguish them.
 @c Real 4.4BSD now runs on some Suns.
 
 There is a shell script called @file{config.sub} that you can use
 as a subroutine to validate system types and canonicalize aliases.
 
+@cindex optional features, configure-time
 Other options are permitted to specify in more detail the software
 or hardware present on the machine, and include or exclude optional
 parts of the package:
@@ -3166,17 +3457,6 @@ and
 Do not use a @samp{--with} option to specify the file name to use to
 find certain files.  That is outside the scope of what @samp{--with}
 options are for.
-
-@item --nfp
-The target machine has no floating point processor.
-
-@item --gas
-The target machine assembler is GAS, the GNU assembler.
-This is obsolete; users should use @samp{--with-gnu-as} instead.
-
-@item --x
-The target machine has the X Window System installed.
-This is obsolete; users should use @samp{--with-x} instead.
 @end table
 
 All @code{configure} scripts should accept all of these ``detail''
@@ -3192,27 +3472,36 @@ you might think of.  That is deliberate.  We want to limit the possible
 configuration options in GNU software.  We do not want GNU programs to
 have idiosyncratic configuration options.
 
-Packages that perform part of the compilation process may support cross-compilation.
-In such a case, the host and target machines for the program may be
-different.  The @code{configure} script should normally treat the
-specified type of system as both the host and the target, thus producing
-a program which works for the same type of machine that it runs on.
+Packages that perform part of the compilation process may support
+cross-compilation.  In such a case, the host and target machines for the
+program may be different.
 
-The way to build a cross-compiler, cross-assembler, or what have you, is
-to specify the option @samp{--host=@var{hosttype}} when running
-@code{configure}.  This specifies the host system without changing the
-type of target system.  The syntax for @var{hosttype} is the same as
-described above.
+The @code{configure} script should normally treat the specified type of
+system as both the host and the target, thus producing a program which
+works for the same type of machine that it runs on.
 
-Bootstrapping a cross-compiler requires compiling it on a machine other
-than the host it will run on.  Compilation packages accept a
-configuration option @samp{--build=@var{hosttype}} for specifying the
-configuration on which you will compile them, in case that is different
-from the host.
+To configure a cross-compiler, cross-assembler, or what have you, you
+should specify a target different from the host, using the configure
+option @samp{--target=@var{targettype}}.  The syntax for
+@var{targettype} is the same as for the host type.  So the command would
+look like this:
+
+@example
+./configure @var{hosttype} --target=@var{targettype}
+@end example
 
 Programs for which cross-operation is not meaningful need not accept the
-@samp{--host} option, because configuring an entire operating system for
-cross-operation is not a meaningful thing.
+@samp{--target} option, because configuring an entire operating system for
+cross-operation is not a meaningful operation.
+
+Bootstrapping a cross-compiler requires compiling it on a machine other
+than the host it will run on.  Compilation packages accept a
+configuration option @samp{--build=@var{buildtype}} for specifying the
+configuration on which you will compile them, but the configure script
+should normally guess the build machine type (using
+@file{config.guess}), so this option is probably not necessary.  The
+host and target types normally default from the build type, so in
+bootstrapping a cross-compiler you must specify them both explicitly.
 
 Some programs have ways of configuring themselves automatically.  If
 your program is set up to do this, your @code{configure} script can simply
@@ -3227,6 +3516,7 @@ ignore most of its arguments.
 
 @node Releases
 @section Making Releases
+@cindex packaging
 
 Package the distribution of @code{Foo version 69.96} up in a gzipped tar
 file with the name @file{foo-69.96.tar.gz}.  It should unpack into a
@@ -3239,6 +3529,7 @@ files} and @dfn{non-source files}.  Source files are written by humans
 and never changed automatically; non-source files are produced from
 source files by programs under the control of the Makefile.
 
+@cindex @file{README} file
 The distribution should contain a file named @file{README} which gives
 the name of the package, and a general description of what it does.  It
 is also good to explain the purpose of each of the first-level
@@ -3297,6 +3588,7 @@ characters both before and after the period.  Thus,
 are truncated to @file{foobarha.c} and @file{foobarha.o}, which are
 distinct.
 
+@cindex @file{texinfo.tex}, in a distribution
 Include in your distribution a copy of the @file{texinfo.tex} you used
 to test print any @file{*.texinfo} or @file{*.texi} files.
 
@@ -3308,6 +3600,7 @@ other files to get.
 
 @node References
 @chapter References to Non-Free Software and Documentation
+@cindex references to non-free material
 
 A GNU program should not recommend use of any non-free program.  We
 can't stop some people from writing proprietary programs, or stop other
@@ -3331,6 +3624,10 @@ we are serious about the need for free documentation, we must not
 undermine our position by recommending use of documentation that isn't
 free.
 
+@node Index
+@unnumbered Index
+@printindex cp
+
 @contents
 
 @bye
@@ -3339,4 +3636,5 @@ update-date-leading-regexp: "@c This date is automagically updated when you save
 update-date-trailing-regexp: ""
 eval: (load "/gd/gnuorg/update-date.el")
 eval: (add-hook 'write-file-hooks 'update-date)
+compile-command: "make just-standards"
 End:
diff --git a/gnu/egcs/gcc/ABOUT-GCC-NLS b/gnu/egcs/gcc/ABOUT-GCC-NLS
index b70a7c8df67..684edb22088 100644
--- a/gnu/egcs/gcc/ABOUT-GCC-NLS
+++ b/gnu/egcs/gcc/ABOUT-GCC-NLS
@@ -1,10 +1,26 @@
 Notes on GCC's Native Language Support
 
 GCC's Native Language Support (NLS) is relatively new and
-experimental, so NLS is currently disabled by default.  Use
-configure's --enable-nls option to enable it.  Eventually, NLS will be
-enabled by default, and you'll need --disable-nls to disable it.  You
-must enable NLS in order to make a GCC distribution.
+experimental, so NLS is currently disabled by default.
+
+The main reason for it being buggy is, that GCC does not set the
+locale categories correctly.  Currently only LC_MESSAGES is set if the
+system supports it and else nothing.  To work correctly, GCC would have
+to also set the character set used by the terminal by either setting
+LC_CTYPE together with LC_MESSAGES or LC_ALL if LC_MESSAGES is
+not supported.
+
+This would change the behaviour of GCC in quite a few places because
+a number of standard C functions and macros change their behaviour
+depending on the locale.  These necessary changes have been done in the
+development version, but these changes are beyond the scope
+of a maintenance release such as this.  It is therefore recommended that
+you leave it disabled.
+
+If you still want to enable the feature, use configure's --enable-nls
+option to enable it.  Eventually, NLS will be enabled by default, and
+you'll need --disable-nls to disable it.  You must enable NLS in order
+to make a GCC distribution.
 
 By and large, only diagnostic messages have been internationalized.
 Some work remains in other areas; for example, GCC does not yet allow
diff --git a/gnu/egcs/gcc/NEWS b/gnu/egcs/gcc/NEWS
index 427df254eb6..d66c6e86ecd 100644
--- a/gnu/egcs/gcc/NEWS
+++ b/gnu/egcs/gcc/NEWS
@@ -1,1071 +1,1540 @@
-Noteworthy changes in GCC after EGCS 1.1.
------------------------------------------
-
-Target specific NEWS
-
-    RS6000/PowerPC: -mcpu=401 was added as an alias for -mcpu=403.  -mcpu=e603e
-		    was added to do -mcpu=603e and -msoft-float.
-
-Noteworthy changes in GCC for EGCS 1.1.
----------------------------------------
-
-The compiler now implements global common subexpression elimination (gcse) as
-well as global constant/copy propagation.  (link to gcse page).
-
-More major improvements have been made to the alias analysis code.  A new
-option to allow front-ends to provide alias information to the optimizers
-has also been added (-fstrict-aliasing).  -fstrict-aliasing is off by default
-now, but will be enabled by default in the future. (link to alias page)
-
-Major changes continue in the exception handling support.  This release
-includes some changes to reduce static overhead for exception handling.  It
-also includes some major changes to the setjmp/longjmp based EH mechanism to
-make it less pessimistic.  And finally, major infrastructure improvements
-to the dwarf2 EH mechanism have been made to make our EH support extensible.
-
-We have fixed the infamous security problems with temporary files. 
-
-The "regmove" optimization pass has been nearly completely rewritten.  It now
-uses much more information about the target to determine profitability of
-transformations.
-
-The compiler now recomputes register usage information immediately before
-register allocation.  Previously such information was only not kept up to
-date after instruction combination which led to poor register allocation
-choices by our priority based register allocator.
-
-The register reloading phase of the compiler has been improved to better
-optimize spill code.  This primarily helps targets which generate lots of
-spills (like the x86 ports and many register poor embedded ports).
-
-A few changes in the heuristics used by the register allocator and scheduler
-have been made which can significantly improve performance for certain
-applications.
-
-The compiler's branch shortening algorithms have been significantly improved
-to work better on targets which align jump targets.
-
-The compiler now supports the "ADDRESSOF" optimization which can significantly
-reduce the overhead for certain inline calls (and inline calls in general).
-
-The compiler now supports a code size optimization switch (-Os).  When enabled
-the compiler will prefer optimizations which improve code size over those
-which improve code speed.
-
-The compiler has been improved to completely eliminate library calls which
-compute constant values.  This is particularly useful on machines which
-do not have integer mul/div or floating point support on-chip.
-
-GCC now supports a "--help" option to print detailed help information.
-
-cpplib has been greatly improved.  It is probably useable for some sites now
-(major missing feature is trigraphs).
-
-Memory footprint for the compiler has been significantly reduced for certain
-pathalogical cases.
-
-Build time improvements for targets which support lots of sched parameters
-(alpha and mips primarily).
-
-Compile time for certain programs using large constant initializers has been
-improved (effects glibc significantly).
-
-Plus an incredible number of infrastructure changes, warning fixes, bugfixes
-and local optimizations.
-
-Various improvements have been made to better support cross compilations.  They
-are still not easy, but they are improving.
-
-Target specific NEWS
-
-    Sparc: Now includes V8 plus and V9 support, lots of tuning for Ultrasparcs
-           and uses the Haifa scheduler by default.
-
-    Alpha: EV6 tuned, optimized expansion of memcpy/bzero.
-
-    x86: Data in the static store is aligned per Intel recommendations.  Jump
-         targets are aligned per Intel recommendations.  Improved epilogue
-         sequences for Pentium chips.  Backend improvements which should help
-         register allocation on all x86 variants.  Support for PPro conditional
-         move instructions has been fixed and enabled.  Random changes
-	 throughout the port to make generated code more Pentium friendly.
-         Improved support for 64bit integer operations.
-         Unixware 7, a System V Release 5 target is now supported.
-         SCO OpenServer targets can support GAS.  See gcc/INSTALL for details.
-
-    RS6000/PowerPC: Includes AIX4.3 support as well as PowerPC64 support.  
-                    Haifa instruction scheduling is enabled by default now.
-
-    MIPS: Multiply/Multiply-Add support has been largely rewritten to generate
-          more efficient code.  Includes mips16 support.
-
-    M68K: Various micro-optimizations and Coldfire fixes.
-
-    M32r: Major improvements to this port.
-
-    Arm: Includes Thumb and super interworking support.
-
-EGCS includes all gcc2 changes up to and including the June 9, 1998 snapshot.
-
-
-Noteworthy changes in GCC version 2.8.1
----------------------------------------
-
-Numerous bugs have been fixed and some minor performance
-improvements (compilation speed) have been made.
-
-Noteworthy changes in GCC version 2.8.0
----------------------------------------
-
-A major change in this release is the addition of a framework for
-exception handling, currently used by C++.  Many internal changes and
-optimization improvements have been made.  These increase the
-maintainability and portability of GCC.  GCC now uses autoconf to
-compute many host parameters.
-
-The following lists changes that add new features or targets.
-
-See cp/NEWS for new features of C++ in this release.
-
-New tools and features:
-
-    The Dwarf 2 debugging information format is supported on ELF systems, and
-    is the default for -ggdb where available.  It can also be used for C++.
-    The Dwarf version 1 debugging format is also permitted for C++, but
-    does not work well.
-
-    gcov.c is provided for test coverage analysis and branch profiling
-    analysis is also supported; see -fprofile-arcs, -ftest-coverage,
-    and -fbranch-probabilities.
-
-    Support for the Checker memory checking tool.
-
-    New switch, -fstack-check, to check for stack overflow on systems that
-    don't have such built into their ABI.
-
-    New switches, -Wundef and -Wno-undef to warn if an undefined identifier
-    is evaluated in an #if directive.
-
-    Options -Wall and -Wimplicit now cause GCC to warn about implicit int
-    in declarations (e.g. `register i;'), since the C Standard committee
-    has decided to disallow this in the next revision of the standard;
-    -Wimplicit-function-declarations and -Wimplicit-int are subsets of
-    this.
-
-    Option -Wsign-compare causes GCC to warn about comparison of signed and
-    unsigned values.
-
-    Add -dI option of cccp for cxref.
-
-New features in configuration, installation and specs file handling:
-
-    New option --enable-c-cpplib to configure script.
-
-    You can use --with-cpu on the configure command to specify the default
-    CPU that GCC should generate code for.
-
-    The -specs=file switch allows you to override default specs used in
-    invoking programs like cc1, as, etc.
-
-    Allow including one specs file from another and renaming a specs
-    variable.
-
-    You can now relocate all GCC files with a single environment variable
-    or a registry entry under Windows 95 and Windows NT.
-
-Changes in Objective-C:
-
-    The Objective-C Runtime Library has been made thread-safe.
-
-    The Objective-C Runtime Library contains an interface for creating
-    mutexes, condition mutexes, and threads; it requires a back-end
-    implementation for the specific platform and/or thread package.
-    Currently supported are DEC/OSF1, IRIX, Mach, OS/2, POSIX, PCThreads,
-    Solaris, and Windows32.  The --enable-threads parameter can be used
-    when configuring GCC to enable and select a thread back-end.
-
-    Objective-C is now configured as separate front-end language to GCC,
-    making it more convenient to conditionally build it.
-
-    The internal structures of the Objective-C Runtime Library have
-    changed sufficiently to warrant a new version number; now version 8.
-    Programs compiled with an older version must be recompiled.
-
-    The Objective-C Runtime Library can be built as a DLL on Windows 95
-    and Windows NT systems.
-    
-    The Objective-C Runtime Library implements +load.
-
-The following new targets are supported (see also list under each
-individual CPU below):
-
-    Embedded target m32r-elf.
-    Embedded Hitachi Super-H using ELF.
-    RTEMS real-time system on various CPU targets.
-    ARC processor.
-    NEC V850 processor.
-    Matsushita MN10200 processor.
-    Matsushita MN10300 processor.
-    Sparc and PowerPC running on VxWorks.
-    Support both glibc versions 1 and 2 on Linux-based GNU systems.
-
-New features for DEC Alpha systems:
-
-    Allow detailed specification of IEEE fp support:
-      -mieee, -mieee-with-inexact, and -mieee-conformant
-      -mfp-trap-mode=xxx, -mfp-round-mode=xxx, -mtrap-precision=xxx
-    -mcpu=xxx for CPU selection
-    Support scheduling parameters for EV5.
-    Add support for BWX, CIX, and MAX instruction set extensions.
-    Support Linux-based GNU systems.
-    Support VMS.
-
-Additional supported processors and systems for MIPS targets:
-
-    MIPS4 instruction set.
-    R4100, R4300 and R5000 processors.
-    N32 and N64 ABI.
-    IRIX 6.2.
-    SNI SINIX.
-    
-New features for Intel x86 family:
-
-    Add scheduling parameters for Pentium and Pentium Pro.
-    Support stabs on Solaris-x86.
-    Intel x86 processors running the SCO OpenServer 5 family.
-    Intel x86 processors running DG/UX.
-    Intel x86 using Cygwin32 or Mingw32 on Windows 95 and Windows NT.
-
-New features for Motorola 68k family:
-
-    Support for 68060 processor.
-    More consistent switches to specify processor.
-    Motorola 68k family running AUX.
-    68040 running pSOS, ELF object files, DBX debugging.
-    Coldfire variant of Motorola m68k family.
-
-New features for the HP PA RISC:
-
-    -mspace and -mno-space
-    -mlong-load-store and -mno-long-load-store
-    -mbig-switch -mno-big-switch
-
-    GCC on the PA requires either gas-2.7 or the HP assembler; for best
-    results using GAS is highly recommended.  GAS is required for -g and
-    exception handling support.
-
-New features for SPARC-based systems:
-
-    The ultrasparc cpu.
-    The sparclet cpu, supporting only a.out file format.
-    Sparc running SunOS 4 with the GNU assembler.
-    Sparc running the Linux-based GNU system.
-    Embedded Sparc processors running the ELF object file format.
-    -mcpu=xxx
-    -mtune=xxx
-    -malign-loops=xxx
-    -malign-jumps=xxx
-    -malign-functions=xxx
-    -mimpure-text and -mno-impure-text
-
-    Options -mno-v8 and -mno-sparclite are no longer supported on SPARC
-    targets.  Options -mcypress, -mv8, -msupersparc, -msparclite, -mf930,
-    and -mf934 are deprecated and will be deleted in GCC 2.9.  Use
-    -mcpu=xxx instead.
-
-New features for rs6000 and PowerPC systems:
-
-    Solaris 2.51 running on PowerPC's.
-    The Linux-based GNU system running on PowerPC's.
-    -mcpu=604e,602,603e,620,801,823,mpc505,821,860,power2
-    -mtune=xxx
-    -mrelocatable-lib, -mno-relocatable-lib
-    -msim, -mmve, -memb
-    -mupdate, -mno-update
-    -mfused-madd, -mno-fused-madd
-
-    -mregnames
-    -meabi
-    -mcall-linux, -mcall-solaris, -mcall-sysv-eabi, -mcall-sysv-noeabi
-    -msdata, -msdata=none, -msdata=default, -msdata=sysv, -msdata=eabi
-    -memb, -msim, -mmvme
-    -myellowknife, -mads
-    wchar_t is now of type long as per the ABI, not unsigned short.
-    -p/-pg support
-    -mcpu=403 now implies -mstrict-align.
-    Implement System V profiling.
-
-    Aix 4.1 GCC targets now default to -mcpu=common so that programs
-    compiled can be moved between rs6000 and powerpc based systems.  A
-    consequence of this is that -static won't work, and that some programs
-    may be slightly slower.
-
-    You can select the default value to use for -mcpu=xxx on rs6000 and
-    powerpc targets by using the --with-cpu=xxx option when configuring the
-    compiler.  In addition, a new options, -mtune=xxx was added that
-    selects the machine to schedule for but does not select the
-    architecture level.
-
-    Directory names used for storing the multilib libraries on System V
-    and embedded PowerPC systems have been shortened to work with commands
-    like tar that have fixed limits on pathname size.
-
-New features for the Hitachi H8/300(H):
-
-    -malign-300
-    -ms (for the Hitachi H8/S processor)
-    -mint32
-
-New features for the ARM:
-
-    -march=xxx, -mtune=xxx, -mcpu=xxx
-    Support interworking with Thumb code.
-    ARM processor with a.out object format, COFF, or AOF assembler.
-    ARM on "semi-hosted" platform.
-    ARM running NetBSD.
-    ARM running the Linux-based GNU system.
-
-New feature for Solaris systems:
-
-    GCC installation no longer makes a copy of system include files,
-    thus insulating GCC better from updates to the operating system.
-
-
-Noteworthy changes in GCC version 2.7.2
----------------------------------------
-
-A few bugs have been fixed (most notably the generation of an
-invalid assembler opcode on some RS/6000 systems).
-
-Noteworthy changes in GCC version 2.7.1
----------------------------------------
-
-This release fixes numerous bugs (mostly minor) in GCC 2.7.0, but
-also contains a few new features, mostly related to specific targets.
-
-Major changes have been made in code to support Windows NT.
-
-The following new targets are supported:
-
-	2.9 BSD on PDP-11
-	Linux on m68k
-	HP/UX version 10 on HP PA RISC (treated like version 9)
-	DEC Alpha running Windows NT
-
-When parsing C, GCC now recognizes C++ style `//' comments unless you
-specify `-ansi' or `-traditional'.
-
-The PowerPC System V targets (powerpc-*-sysv, powerpc-*-eabi) now use the
-calling sequence specified in the System V Application Binary Interface
-Processor Supplement (PowerPC Processor ABI Supplement) rather than the calling
-sequence used in GCC version 2.7.0.  That calling sequence was based on the AIX
-calling sequence without function descriptors.  To compile code for that older
-calling sequence, either configure the compiler for powerpc-*-eabiaix or use
-the -mcall-aix switch when compiling and linking.
-
-Noteworthy changes in GCC version 2.7.0
----------------------------------------
-
-GCC now works better on systems that use ".obj" and ".exe" instead of
-".o" and no extension.  This involved changes to the driver program,
-gcc.c, to convert ".o" names to ".obj" and to GCC's Makefile to use
-".obj" and ".exe" in filenames that are not targets.  In order to
-build GCC on such systems, you may need versions of GNU make and/or
-compatible shells.  At this point, this support is preliminary.
-
-Object file extensions of ".obj" and executable file extensions of
-".exe" are allowed when using appropriate version of GNU Make.
-
-Numerous enhancements were made to the __attribute__ facility including
-more attributes and more places that support it.  We now support the
-"packed", "nocommon", "noreturn", "volatile", "const", "unused",
-"transparent_union", "constructor", "destructor", "mode", "section",
-"align", "format", "weak", and "alias" attributes.  Each of these
-names may also be specified with added underscores, e.g., "__packed__".
-__attribute__ may now be applied to parameter definitions, function
-definitions, and structure, enum, and union definitions.
-
-GCC now supports returning more structures in registers, as specified by
-many calling sequences (ABIs), such as on the HP PA RISC.
-
-A new option '-fpack-struct' was added to automatically pack all structure
-members together without holes.
-
-There is a new library (cpplib) and program (cppmain) that at some
-point will replace cpp (aka cccp).  To use cppmain as cpp now, pass
-the option CCCP=cppmain to make.  The library is already used by the
-fix-header program, which should speed up the fixproto script.
-
-New options for supported targets:
-
-    GNU on many targets.
-    NetBSD on MIPS, m68k, VAX, and x86.
-    LynxOS on x86, m68k, Sparc, and RS/6000.
-    VxWorks on many targets.
-
-    Windows/NT on x86 architecture.  Initial support for Windows/NT on Alpha
-    (not fully working).
-
-    Many embedded targets, specifically UDI on a29k, aout, coff, elf,
-    and vsta "operating systems" on m68k, m88k, mips, sparc, and x86.
-
-Additional support for x86 (i386, i486, and Pentium):
-
-    Work with old and new linkers for Linux-based GNU systems,
-	supporting both a.out and ELF.
-    FreeBSD on x86.
-    Stdcall convention.
-    -malign-double, -mregparm=, -malign-loops= and -malign-jumps=  switches.
-    On ISC systems, support -Xp like -posix.
-
-Additions for RS/6000:
-
-    Instruction scheduling information for PowerPC 403.
-    AIX 4.1 on PowerPC.
-    -mstring and -mno-string.
-    -msoft-float and floating-point emulation included.
-    Preliminary support for PowerPC System V.4 with or without the GNU as.
-    Preliminary support for EABI.
-    Preliminary support for 64-bit systems.
-    Both big and little endian systems.
-
-New features for MIPS-based systems:
-
-    r4650.
-    mips4 and R8000.
-    Irix 6.0.
-    64-bit ABI.
-    Allow dollar signs in labels on SGI/Irix 5.x.
-
-New support for HP PA RISC:
-
-    Generation of PIC (requires binutils-2.5.2.u6 or later).
-    HP-UX version 9 on HP PA RISC (dynamically links even with -g).
-    Processor variants for HP PA RISC: 700, 7100, and 7100LC.
-    Automatic generation of long calls when needed.
-    -mfast-indirect-calls for kernels and static binaries.
-
-    The called routine now copies arguments passed by invisible reference,
-    as required by the calling standard.
-
-Other new miscellaneous target-specific support:
-
-    -mno-multm on a29k.
-    -mold-align for i960.
-    Configuration for "semi-hosted" ARM.
-    -momit-leaf-frame-pointer for M88k.
-    SH3 variant of Hitachi Super-H and support both big and little endian.
-
-Changes to Objective-C:
-
-    Bare-bones implementation of NXConstantString has been added,
-    which is invoked by the @"string" directive.
-
-    Class * has been changed to Class to conform to the NextSTEP and
-    OpenStep runtime.
-
-    Enhancements to make dynamic loading easier.
-
-    The module version number has been updated to Version 7, thus existing
-    code will need to be recompiled to use the current run-time library.
-
-GCC now supports the ISO Normative Addendum 1 to the C Standard.
-As a result:
-
-    The header <iso646.h> defines macros for C programs written
-    in national variants of ISO 646.
-
-    The following digraph tokens are supported:
-	<:	:>	<%	%>	%:	%:%:
-    These behave like the following, respectively:
-	[	]	{	}	#	##
-
-    Digraph tokens are supported unless you specify the `-traditional'
-    option; you do not need to specify `-ansi' or `-trigraphs'.  Except
-    for contrived and unlikely examples involving preprocessor
-    stringizing, digraph interpretation doesn't change the meaning of
-    programs; this is unlike trigraph interpretation, which changes the
-    meanings of relatively common strings.
-
-    The macro __STDC_VERSION__ has the value 199409L.
-
-  As usual, for full conformance to the standard, you also need a
-  C library that conforms.
-
-The following lists changes that have been made to g++.  If some
-features mentioned below sound unfamiliar, you will probably want to
-look at the recently-released public review copy of the C++ Working
-Paper.  For PostScript and PDF (Adobe Acrobat) versions, see the
-archive at ftp://research.att.com/dist/stdc++/WP.  For HTML and ASCII
-versions, see ftp://ftp.cygnus.com/pub/g++.  On the web, see
-http://www.cygnus.com/~mrs/wp-draft.
-
-The scope of variables declared in the for-init-statement has been changed
-to conform to http://www.cygnus.com/~mrs/wp-draft/stmt.html#stmt.for; as a
-result, packages such as groff 1.09 will not compile unless you specify the
--fno-for-scope flag.  PLEASE DO NOT REPORT THIS AS A BUG; this is a change
-mandated by the C++ standardization committee.
-
-Binary incompatibilities:
-
-    The builtin 'bool' type is now the size of a machine word on RISC targets,
-    for code efficiency; it remains one byte long on CISC targets.
-
-    Code that does not use #pragma interface/implementation will most
-    likely shrink dramatically, as g++ now only emits the vtable for a
-    class in the translation unit where its first non-inline, non-abstract
-    virtual function is defined.
-
-    Classes that do not define the copy constructor will sometimes be
-    passed and returned in registers.  This may illuminate latent bugs in
-    your code.
-
-Support for automatic template instantiation has *NOT* been added, due
-to a disagreement over design philosophies.
-
-Support for exception handling has been improved; more targets are now
-supported, and throws will use the RTTI mechanism to match against the
-catch parameter type.  Optimization is NOT SUPPORTED with
--fhandle-exceptions; no need to report this as a bug.
-
-Support for Run-Time Type Identification has been added with -frtti.
-This support is still in alpha; one major restriction is that any file
-compiled with -frtti must include <typeinfo.h>.
-
-Preliminary support for namespaces has been added.  This support is far
-from complete, and probably not useful.
-
-Synthesis of compiler-generated constructors, destructors and
-assignment operators is now deferred until the functions are used.
-
-The parsing of expressions such as `a ? b : c = 1' has changed from
-`(a ? b : c) = 1' to `a : b ? (c = 1)'.
-
-The code generated for testing conditions, especially those using ||
-and &&, is now more efficient.
-
-The operator keywords and, and_eq, bitand, bitor, compl, not, not_eq,
-or, or_eq, xor and xor_eq are now supported.  Use -ansi or
--foperator-names to enable them.
-
-The 'explicit' keyword is now supported.  'explicit' is used to mark
-constructors and type conversion operators that should not be used
-implicitly.
-
-g++ now accepts the typename keyword, though it currently has no
-semantics; it can be a no-op in the current template implementation.
-You may want to start using it in your code, however, since the
-pending rewrite of the template implementation to compile STL properly
-(perhaps for 2.8.0, perhaps not) will require you to use it as
-indicated by the current draft.
-
-Handling of user-defined type conversion has been overhauled so that
-type conversion operators are now found and used properly in
-expressions and function calls.
-
--fno-strict-prototype now only applies to function declarations with
-"C" linkage.
-
-g++ now warns about 'if (x=0)' with -Wparentheses or -Wall.
-
-#pragma weak and #pragma pack are supported on System V R4 targets, as
-are various other target-specific #pragmas supported by gcc.
-
-new and delete of const types is now allowed (with no additional
-semantics).
-
-Explicit instantiation of template methods is now supported.  Also,
-'inline template class foo<int>;' can be used to emit only the vtable
-for a template class.
-
-With -fcheck-new, g++ will check the return value of all calls to
-operator new, and not attempt to modify a returned null pointer.
-
-The template instantiation code now handles more conversions when
-passing to a parameter that does not depend on template arguments.
-This means that code like 'string s; cout << s;' now works.
-
-Invalid jumps in a switch statement past declarations that require
-initializations are now caught.
-
-Functions declared 'extern inline' now have the same linkage semantics
-as inline member functions.  On supported targets, where previously
-these functions (and vtables, and template instantiations) would have
-been defined statically, they will now be defined as weak symbols so
-that only one out-of-line definition is used.
-
-collect2 now demangles linker output, and c++filt has become part of
-the gcc distribution.
-
-Noteworthy changes in GCC version 2.6.3:
-
-A few more bugs have been fixed.
-
-Noteworthy changes in GCC version 2.6.2:
-
-A few bugs have been fixed.
-
-Names of attributes can now be preceded and followed by double underscores.
-
-Noteworthy changes in GCC version 2.6.1:
-
-Numerous (mostly minor) bugs have been fixed.
-
-The following new configurations are supported:
-
-	GNU on x86 (instead of treating it like MACH)
-	NetBSD on Sparc and Motorola 68k
-	AIX 4.1 on RS/6000 and PowerPC systems
-	Sequent DYNIX/ptx 1.x and 2.x.
-	Both COFF and ELF configurations on AViiON without using /bin/gcc
-	Windows/NT on x86 architecture; preliminary
-	AT&T DSP1610 digital signal processor chips
-	i960 systems on bare boards using COFF
-	PDP11; target only and not extensively tested
-
-The -pg option is now supported for Alpha under OSF/1 V3.0 or later.
-
-Files with an extension of ".c++" are treated as C++ code.
-
-The -Xlinker and -Wl arguments are now passed to the linker in the
-position they were specified on the command line.  This makes it
-possible, for example, to pass flags to the linker about specific
-object files.
-
-The use of positional arguments to the configure script is no longer
-recommended.  Use --target= to specify the target; see the GCC manual.
-
-The 386 now supports two new switches: -mreg-alloc=<string> changes
-the default register allocation order used by the compiler, and
--mno-wide-multiply disables the use of the mul/imul instructions that
-produce 64 bit results in EAX:EDX from 32 bit operands to do long long
-multiplies and 32-bit division by constants.
-
-Noteworthy changes in GCC version 2.6.0:
-
-Numerous bugs have been fixed, in the C and C++ front-ends, as
-well as in the common compiler code.
-
-This release includes the C, Objective-C, and C++ compilers.  However,
-we have moved the files for the C++ compiler (G++) files to a
-subdirectory, cp.  Subsequent releases of GCC will split these files
-to a separate TAR file.
-
-The G++ team has been tracking the development of the ANSI standard for C++.
-Here are some new features added from the latest working paper:
-
-	* built-in boolean type 'bool', with constants 'true' and 'false'.
-	* array new and delete (operator new [] and delete []).
-	* WP-conforming lifetime of temporaries.
-	* explicit instantiation of templates (template class A<int>;),
-          along with an option (-fno-implicit-templates) to disable emission
-          of implicitly instantiated templates, obsoletes -fexternal-templates.
-	* static member constants (static const int foo = 4; within the
-          class declaration).
-
-Many error messages have been improved to tell the user more about the
-problem.  Conformance checking with -pedantic-errors has been
-improved.  G++ now compiles Fresco.
-
-There is now an experimental implementation of virtual functions using
-thunks instead of Cfront-style vtables, enabled with -fvtable-thunks.
-This option also enables a heuristic which causes the compiler to only
-emit the vtable in the translation unit where its first non-inline
-virtual function is defined; using this option and
--fno-implicit-templates, users should be able to avoid #pragma
-interface/implementation altogether.
-
-Signatures have been added as a GNU C++ extension.  Using the option
--fhandle-signatures, users are able to turn on recognition of
-signatures.  A short introduction on signatures is in the section
-`Extension to the C++ Language' in the manual.
-
-The `g++' program is now a C program, rather than a shell script.
-
-Lots and lots and lots of bugs fixes, in nested types, access control,
-pointers to member functions, the parser, templates, overload
-resolution, etc, etc.
-
-There have been two major enhancements to the Objective-C compiler:
-
-1) Added portability.  It now runs on Alpha, and some problems with
-   message forwarding have been addressed on other platforms.
-
-2) Selectors have been redefined to be pointers to structs like:
-   { void *sel_id, char *sel_types }, where the sel_id is the unique
-   identifier, the selector itself is no longer unique.  
-
-   Programmers should use the new function sel_eq to test selector
-   equivalence.
-
-The following major changes have been made to the base compiler and
-machine-specific files.
-
-- The MIL-STD-1750A is a new port, but still preliminary.
-
-- The h8/300h is now supported; both the h8/300 and h8/300h ports come
-  with 32 bit IEEE 754 software floating point support.
-
-- The 64-bit Sparc (v9) and 64-bit MIPS chips are supported.
-
-- NetBSD is supported on m68k, Intel x86, and pc523 systems and FreeBSD
-  on x86.
-
-- COFF is supported on x86, m68k, and Sparc systems running LynxOS.
-
-- 68K systems from Bull and Concurrent are supported and System V
-  Release 4 is supported on the Atari.
-
-- GCC supports GAS on the Motorola 3300 (sysV68) and debugging
-  (assuming GAS) on the Plexus 68K system.  (However, GAS does not yet
-  work on those systems).
-
-- System V Release 4 is supported on MIPS (Tandem).
-
-- For DG/UX, an ELF configuration is now supported, and both the ELF
-  and BCS configurations support ELF and COFF object file formats.
-
-- OSF/1 V2.0 is supported on Alpha.
-
-- Function profiling is also supported on Alpha.
-
-- GAS and GDB is supported for Irix 5 (MIPS).
-
-- "common mode" (code that will run on both POWER and PowerPC
-  architectures) is now supported for the RS/6000 family; the
-  compiler knows about more PPC chips.
-
-- Both NeXTStep 2.1 and 3 are supported on 68k-based architectures.
-
-- On the AMD 29k, the -msoft-float is now supported, as well as
-  -mno-sum-in-toc for RS/6000, -mapp-regs and -mflat for Sparc, and
-  -membedded-pic for MIPS.
-
-- GCC can now convert division by integer constants into the equivalent
-  multiplication and shift operations when that is faster than the
-  division.
-	
-- Two new warning options, -Wbad-function-cast and
-  -Wmissing-declarations have been added.
-
-- Configurations may now add machine-specific __attribute__ options on
-  type; many machines support the `section' attribute.
-
-- The -ffast-math flag permits some optimization that violate strict
-  IEEE rules, such as converting X * 0.0 to 0.0.
-
-Noteworthy changes in GCC version 2.5.8:
-
-This release only fixes a few serious bugs.  These include fixes for a
-bug that prevented most programs from working on the RS/6000, a bug
-that caused invalid assembler code for programs with a `switch'
-statement on the NS32K, a G++ problem that caused undefined names in
-some configurations, and several less serious problems, some of which
-can affect most configuration.
-
-Noteworthy change in GCC version 2.5.7:
-
-This release only fixes a few bugs, one of which was causing bootstrap
-compare errors on some systems.
-
-Noteworthy change in GCC version 2.5.6:
-
-A few backend bugs have been fixed, some of which only occur on one
-machine.
-
-The C++ compiler in 2.5.6 includes:
-
- * fixes for some common crashes
- * correct handling of nested types that are referenced as `foo::bar'
- * spurious warnings about friends being declared static and never
-   defined should no longer appear
- * enums that are local to a method in a class, or a class that's
-   local to a function, are now handled correctly.  For example:
-       class foo { void bar () { enum { x, y } E; x; } };
-       void bar () { class foo { enum { x, y } E; E baz; }; }
-
-Noteworthy change in GCC version 2.5.5:
-
-A large number of C++ bugs have been fixed.
-
-The fixproto script adds prototypes conditionally on __cplusplus.
-
-Noteworthy change in GCC version 2.5.4:
-
-A bug fix in passing of structure arguments for the HP-PA architecture
-makes code compiled with GCC 2.5.4 incompatible with code compiled
-with earlier versions (if it passes struct arguments of 33 to 64 bits,
-interspersed with other types of arguments).
-
-Noteworthy change in gcc version 2.5.3:
-
-The method of "mangling" C++ function names has been changed.  So you
-must recompile all C++ programs completely when you start using GCC
-2.5.  Also, GCC 2.5 requires libg++ version 2.5.  Earlier libg++
-versions won't work with GCC 2.5.  (This is generally true--GCC
-version M.N requires libg++ version M.N.)
-
-Noteworthy GCC changes in version 2.5:
-
-* There is now support for the IBM 370 architecture as a target.
-Currently the only operating system supported is MVS; GCC does not run
-on MVS, so you must produce .s files using GCC as a cross compiler,
-then transfer them to MVS to assemble them.  This port is not reliable
-yet.
-
-* The Power PC is now supported.
-
-* The i860-based Paragon machine is now supported.
-
-* The Hitachi 3050 (an HP-PA machine) is now supported.
-
-* The variable __GNUC_MINOR__ holds the minor version number of GCC, as
-an integer.  For version 2.5.X, the value is 5.
-
-* In C, initializers for static and global variables are now processed
-an element at a time, so that they don't need a lot of storage.
-
-* The C syntax for specifying which structure field comes next in an
-initializer is now `.FIELDNAME='.  The corresponding syntax for
-array initializers is now `[INDEX]='.  For example,
-
-  char whitespace[256]
-    = { [' '] = 1, ['\t'] = 1, ['\n'] = 1 };
-
-This was changed to accord with the syntax proposed by the Numerical
-C Extensions Group (NCEG).
-
-* Complex numbers are now supported in C.  Use the keyword __complex__
-to declare complex data types.  See the manual for details.
-
-* GCC now supports `long double' meaningfully on the Sparc (128-bit
-floating point) and on the 386 (96-bit floating point).  The Sparc
-support is enabled on Solaris 2.x because earlier system versions
-(SunOS 4) have bugs in the emulation.
-
-* All targets now have assertions for cpu, machine and system.  So you
-can now use assertions to distinguish among all supported targets.
-
-* Nested functions in C may now be inline.  Just declare them inline
-in the usual way.
-
-* Packed structure members are now supported fully; it should be possible 
-to access them on any supported target, no matter how little alignment
-they have.
-
-* To declare that a function does not return, you must now write
-something like this (works only in 2.5):
-
-    void fatal () __attribute__ ((noreturn));
-
-or like this (works in older versions too):
-
-    typedef void voidfn ();
-
-    volatile voidfn fatal;
-
-It used to be possible to do so by writing this:
-
-    volatile void fatal ();
-
-but it turns out that ANSI C requires that to mean something
-else (which is useless).
-
-Likewise, to declare that a function is side-effect-free
-so that calls may be deleted or combined, write
-something like this (works only in 2.5):
-
-    int computation () __attribute__ ((const));
-
-or like this (works in older versions too):
-
-    typedef int intfn ();
-
-    const intfn computation;
-
-* The new option -iwithprefixbefore specifies a directory to add to 
-the search path for include files in the same position where -I would
-put it, but uses the specified prefix just like -iwithprefix.
-
-* Basic block profiling has been enhanced to record the function the
-basic block comes from, and if the module was compiled for debugging,
-the line number and filename.  A default version of the basic block
-support module has been added to libgcc2 that appends the basic block
-information to a text file 'bb.out'.  Machine descriptions can now
-override the basic block support module in the target macro file.
-
-New features in g++:
-
-* The new flag `-fansi-overloading' for C++.  Use a newly implemented
-scheme of argument matching for C++.  It makes g++ more accurately
-obey the rules set down in Chapter 13 of the Annotated C++ Reference
-Manual (the ARM).  This option will be turned on by default in a
-future release.
-
-* The -finline-debug flag is now gone (it was never really used by the
-  compiler).
-
-* Recognizing the syntax for pointers to members, e.g., "foo::*bar", has been
-  dramatically improved.  You should not get any syntax errors or incorrect
-  runtime results while using pointers to members correctly; if you do, it's
-  a definite bug.
-
-* Forward declaration of an enum is now flagged as an error.
-
-* Class-local typedefs are now working properly.
-
-* Nested class support has been significantly improved.  The compiler
-  will now (in theory) support up to 240 nested classes before hitting
-  other system limits (like memory size).
-
-* There is a new C version of the `g++' driver, to replace the old
-  shell script.  This should significantly improve the performance of
-  executing g++ on a system where a user's PATH environment variable
-  references many NFS-mounted filesystems.  This driver also works
-  under MS-DOS and OS/2.
-
-* The ANSI committee working on the C++ standard has adopted a new
-  keyword `mutable'.  This will allow you to make a specific member be
-  modifiable in an otherwise const class.
-
-Noteworthy GCC changes in version 2.4.4:
-
-  A crash building g++ on various hosts (including m68k) has been
-  fixed.  Also the g++ compiler no longer reports incorrect
-  ambiguities in some situations where they do not exist, and
-  const template member functions are now being found properly.
-
-Noteworthy GCC changes in version 2.4:
-
-* On each target, the default is now to return short structures
-compatibly with the "usual" compiler on that target.
-
-For most targets, this means the default is to return all structures
-in memory, like long structures, in whatever way is used on that
-target.  Use -freg-struct-return to enable returning short structures
-(and unions) in registers.
-
-This change means that newly compiled binaries are incompatible with
-binaries compiled with previous versions of GCC.
-
-On some targets, GCC is itself the usual compiler.  On these targets,
-the default way to return short structures is still in registers.
-Use -fpcc-struct-return to tell GCC to return them in memory.
-
-* There is now a floating point emulator which can imitate the way all
-supported target machines do floating point arithmetic.
-
-This makes it possible to have cross compilation to and from the VAX,
-and between machines of different endianness.  However, this works
-only when the target machine description is updated to use the new
-facilities, and not all have been updated.
-
-This also makes possible support for longer floating point types.
-GCC 2.4 supports extended format on the 68K if you use `long double',
-for targets that have a 68881.  (When we have run time library
-routines for extended floating point, then `long double' will use
-extended format on all 68K targets.)
-
-We expect to support extended floating point on the i386 and Sparc in
-future versions.
-
-* Building GCC now automatically fixes the system's header files.
-This should require no attention.
-
-* GCC now installs an unsigned data type as size_t when it fixes the
-header files (on all but a handful of old target machines).
-Therefore, the bug that size_t failed to be unsigned is fixed.
-
-* Building and installation are now completely separate.
-All new files are constructed during the build process; 
-installation just copies them.
-
-* New targets supported: Clipper, Hitachi SH, Hitachi 8300, and Sparc
-Lite.
-
-* A totally new and much better Objective C run time system is included.
-
-* Objective C supports many new features.  Alas, I can't describe them
-since I don't use that language; however, they are the same ones 
-supported in recent versions of the NeXT operating system.
-
-* The builtin functions __builtin_apply_args, __builtin_apply and
-__builtin_return let you record the arguments and returned
-value of a function without knowing their number or type.
-
-* The builtin string variables __FUNCTION__ and __PRETTY_FUNCTION__
-give the name of the function in the source, and a pretty-printed
-version of the name.  The two are the same in C, but differ in C++.
-
-* Casts to union types do not yield lvalues.
-
-* ## before an empty rest argument discards the preceding sequence
-of non-whitespace characters from the macro definition.
-(This feature is subject to change.)
-
-
-New features specific to C++:
-
-* The manual contains a new section ``Common Misunderstandings with
-GNU C++'' that C++ users should read.
-
-* #pragma interface and #pragma implementation let you use the same
-C++ source file for both interface and implementation.
-However, this mechanism is still in transition.
-
-* Named returned values let you avoid an extra constructor call
-when a function result has a class type.
-
-* The C++ operators <? and >? yield min and max, respectively.
-
-* C++ gotos can exit a block safely even if the block has
-aggregates that require destructors.
-
-* gcc defines the macro __GNUG__ when compiling C++ programs.
-
-* GNU C++ now correctly distinguishes between the prefix and postfix
-forms of overloaded operator ++ and --.  To avoid breaking old
-code, if a class defines only the prefix form, the compiler
-accepts either ++obj or obj++, unless -pedantic is used.
-
-* If you are using version 2.3 of libg++, you need to rebuild it with
-`make CC=gcc' to avoid mismatches in the definition of `size_t'.
-
-Newly documented compiler options:
-
--fnostartfiles
-	Omit the standard system startup files when linking.
-
--fvolatile-global
-	Consider memory references to extern and global data items to
-	be volatile.
-
--idirafter DIR
-	Add DIR to the second include path.
-
--iprefix PREFIX
-	Specify PREFIX for later -iwithprefix options.
-
--iwithprefix DIR
-	Add PREFIX/DIR to the second include path.
-
--mv8
-	Emit Sparc v8 code (with integer multiply and divide).
--msparclite
-	Emit Sparclite code (roughly v7.5).
-
--print-libgcc-file-name
-	Search for the libgcc.a file, print its absolute file name, and exit.
-
--Woverloaded-virtual
-	Warn when a derived class function declaration may be an error
-	in defining a C++ virtual function. 
-
--Wtemplate-debugging
-	When using templates in a C++ program, warn if debugging is
-	not yet fully available.
-
-+eN
-	Control how C++ virtual function definitions are used
-	(like cfront 1.x).
-
+This file contains information about GCC releases which has been
+generated automatically from the online release notes.  This file
+covers releases of GCC (and the former EGCS project) since EGCS 1.0,
+on the line of development that led to GCC 3; for information on GCC
+2.8.1 and older releases of GCC 2, see ONEWS.
+
+======================================================================
+http://gcc.gnu.org/gcc-2.95/gcc-2.95.3.html
+
+                                 GCC 2.95.3
+
+   January 11, 2001
+
+   The GNU project and the GCC developers are pleased to announce the
+   prerelease of GCC version 2.95.3. GCC used to stand for the GNU C
+   Compiler, but since the compiler supports several other languages
+   aside from C, it now stands for the GNU Compiler Collection.
+
+   This is a minor release to address several bugs in the [1]GCC version
+   2.95.2 release.
+
+     * Generic bugfixes and improvements
+          + Fix numerous problems that caused incorrect optimization in
+            the register reloading code.
+          + Fix numerous problems that caused incorrect optimization in
+            the loop optimizer.
+          + Fix setjmp/longjmp based exception handling.
+          + Fix aborts in the functions build_insn_chain and scan_loops
+            under some circumstances.
+          + Fix an alias analysis bug.
+          + Fix an infinite compilation bug in the combiner.
+          + A few problems with complex number support have been fixed.
+          + It is no longer possible for gcc to act as a fork bomb when
+            installed incorrectly.
+          + The -fpack-struct option should be recognized now.
+          + Fixed a bug that caused incorrect code to be generated due to
+            a lost stack adjustment.
+     * Platform specific bugfixes and improvements
+          + Support building ARM toolchains hosted on Windows.
+          + Fix attribute calculations in ARM toolchains.
+          + arm-linux support has been improved.
+          + Fix a PIC failure on sparc targets.
+          + On ix86 targets, the regparm attribute should now work
+            reliably.
+          + Several updates for the h8300 port.
+
+   The whole suite has been extensively [2]regression tested and
+   [3]package tested. It should be reliable and suitable for widespread
+   use.
+
+   The GCC 2.95 release has several new optimizations, new targets, new
+   languages and other new features as compared to EGCS 1.1 or GCC 2.8.
+   See the [4]new features page for a more complete list of new features
+   found in the GCC 2.95 releases.
+
+   The sources include installation instructions in both HTML and
+   plaintext forms in the install directory in the distribution. However,
+   the most up to date [5]installation instructions and [6]build/test
+   status are on the web pages. We will update those pages as new
+   information becomes available.
+
+   The GCC developers would like to thank the numerous people that have
+   contributed new features, test results, bugfixes, etc to GCC. This
+   [7]amazing group of volunteers is what makes GCC successful.
+
+   And finally, we can't in good conscience fail to mention some
+   [8]caveats to using GCC 2.95.3.
+
+   Download GCC 2.95.3 from the [9]GNU FTP server (ftp://ftp.gnu.org)
+   Download GCC 2.95.3 from the [10]GCC FTP server (ftp://gcc.gnu.org)
+   [11]Find a GNU mirror site
+   [12]Find a GCC mirror site
+
+   For additional information about GCC please see the [13]GCC project
+   web server or contact the [14]GCC development mailing list.
+     _________________________________________________________________
+
+
+    [15]The GCC team
+    Last modified 2001-01-11
+
+References
+
+   1. http://gcc.gnu.org/gcc-2.95/gcc-2.95.2.html
+   2. http://gcc.gnu.org/gcc-2.95/regress.html
+   3. http://gcc.gnu.org/gcc-2.95/othertest.html
+   4. http://gcc.gnu.org/gcc-2.95/features.html
+   5. http://gcc.gnu.org/install/index.html
+   6. http://gcc.gnu.org/gcc-2.95/buildstat.html
+   7. http://gcc.gnu.org/thanks.html
+   8. http://gcc.gnu.org/gcc-2.95/caveats.html
+   9. ftp://ftp.gnu.org/pub/gnu/gcc/
+  10. ftp://gcc.gnu.org/pub/gcc/releases/index.html
+  11. http://www.gnu.org/order/ftp.html
+  12. http://gcc.gnu.org/mirrors.html
+  13. http://gcc.gnu.org/index.html
+  14. mailto:gcc@gcc.gnu.org
+  15. http://gcc.gnu.org/about.html
+======================================================================
+http://gcc.gnu.org/gcc-2.95/gcc-2.95.2.html
+
+                                 GCC 2.95.2
+
+   October 27, 1999
+
+   The GNU project and the GCC developers are pleased to announce the
+   release of GCC version 2.95.2. GCC used to stand for the GNU C
+   Compiler, but since the compiler supports several other languages
+   aside from C, it now stands for the GNU Compiler Collection.
+
+   This is a minor release to address several bugs in the GCC version
+   2.95.1 release.
+
+   The -fstrict-aliasing is not enabled by default for GCC 2.95.2. While
+   the optimizations performed by -fstrict-aliasing are valid according
+   to the C and C++ standards, the optimization have caused some
+   problems, particularly with old non-conforming code.
+
+   The GCC developers are experimenting with ways to warn users about
+   code which violates the C/C++ standards, but those warnings are not
+   ready for widespread use at this time. Rather than wait for those
+   warnings the GCC developers have chosen to disable -fstrict-aliasing
+   by default for the GCC 2.95.2 release.
+
+   We strongly encourage developers to find and fix code which violates
+   the C/C++ standards as -fstrict-aliasing may be enabled by default in
+   future releases. Use the option -fstrict-aliasing to re-enable these
+   optimizations.
+
+     * Generic bugfixes and improvements
+          + Fix incorrectly optimized memory reference in global common
+            subexpression elimination (GCSE) optimization pass.
+          + Fix code generation bug in regmove.c in which it could
+            incorrectly change a "const" value.
+          + Fix bug in optimization of conditionals involving volatile
+            memory references.
+          + Avoid over-allocation of stack space for some procedures.
+          + Fixed bug in the compiler which caused incorrect optimization
+            of an obscure series of bit manipulations, shifts and
+            arithmetic.
+          + Fixed register allocator bug which caused teTeX to be
+            mis-compiled on Sparc targets.
+          + Avoid incorrect optimization of degenerate case statements
+            for certain targets such as the ARM.
+          + Fix out of range memory reference in the jump optimizer.
+          + Avoid dereferencing null pointer in fix-header.
+          + Fix test for GCC specific features so that it is possible to
+            bootstrap with gcc-2.6.2 and older versions of GCC.
+          + Fix typo in scheduler which could potentially cause out of
+            range memory accesses.
+          + Avoid incorrect loop reversal which caused incorrect code for
+            certain loops on PowerPC targets.
+          + Avoid incorrect optimization of switch statements on certain
+            targets (for example the ARM).
+     * Platform specific bugfixes and improvements
+          + Work around bug in Sun V5.0 compilers which caused bootstrap
+            comparison failures on Sparc targets.
+          + Fix Sparc backend bug which caused aborts in final.c.
+          + Fix sparc-hal-solaris2* configuration fragments.
+          + Fix bug in sparc block profiling.
+          + Fix obscure code generation bug for the PARISC targets.
+          + Define __STDC_EXT__ for HPUX configurations.
+          + Various POWERPC64 code generation bugfixes.
+          + Fix abort for PPC targets using ELF (ex GNU/Linux).
+          + Fix collect2 problems for AIX targets.
+          + Correct handling of .file directive for PPC targets.
+          + Fix bug in fix_trunc x86 patterns.
+          + Fix x86 port to correctly pop the FP stack for functions that
+            return structures in memory.
+          + Fix minor bug in strlen x86 pattern.
+          + Use stabs debugging instead of dwarf1 for x86-solaris
+            targets.
+          + Fix template repository code to handle leading underscore in
+            mangled names.
+          + Fix weak/weak alias support for OpenBSD.
+          + GNU/Linux for the ARM has C++ compatible include files.
+     * Language & Runtime specific fixes.
+          + Fix handling of constructor attribute in the C front-end
+            which caused problems building the Chill runtime library on
+            some targets.
+          + Fix minor problem merging type qualifiers in the C front-end.
+          + Fix aliasing bug for pointers and references (C/C++).
+          + Fix incorrect "non-constant initializer bug" when
+            -traditional or -fwritable-strings is enabled.
+          + Fix build error for Chill front-end on SunOS.
+          + Do not complain about duplicate instantiations when using
+            -frepo (C++)
+          + Fix array bounds handling in C++ front-end which caused
+            problems with dwarf debugging information in some
+            circumstances.
+          + Fix minor namespace problem.
+          + Fix problem linking java programs.
+
+   The whole suite has been extensively [1]regression tested and
+   [2]package tested. It should be reliable and suitable for widespread
+   use.
+
+   The GCC 2.95 release has several new optimizations, new targets, new
+   languages and other new features as compared to EGCS 1.1 or GCC 2.8.
+   See the [3]new features page for a more complete list of new features
+   found in the GCC 2.95 releases.
+
+   The sources include installation instructions in both HTML and
+   plaintext forms in the install directory in the distribution. However,
+   the most up to date [4]installation instructions and [5]build/test
+   status are on the web pages. We will update those pages as new
+   information becomes available.
+
+   The GCC developers would like to thank the numerous people that have
+   contributed new features, test results, bugfixes, etc to GCC. This
+   [6]amazing group of volunteers is what makes GCC successful.
+
+   And finally, we can't in good conscience fail to mention some
+   [7]caveats to using GCC 2.95.2.
+
+   Download GCC 2.95.2 from the [8]GNU FTP server (ftp://ftp.gnu.org)
+   Download GCC 2.95.2 from the [9]GCC/EGCS FTP server
+   (ftp://gcc.gnu.org)
+   [10]Find a GNU mirror site
+   [11]Find a GCC/EGCS mirror site
+
+   For additional information about GCC please see the [12]GCC project
+   web server or contact the [13]GCC development mailing list.
+     _________________________________________________________________
+
+
+    [14]The GCC team
+    Last modified 2000-11-10
+
+References
+
+   1. http://gcc.gnu.org/gcc-2.95/regress.html
+   2. http://gcc.gnu.org/gcc-2.95/othertest.html
+   3. http://gcc.gnu.org/gcc-2.95/features.html
+   4. http://gcc.gnu.org/install/index.html
+   5. http://gcc.gnu.org/gcc-2.95/buildstat.html
+   6. http://gcc.gnu.org/thanks.html
+   7. http://gcc.gnu.org/gcc-2.95/caveats.html
+   8. ftp://ftp.gnu.org/pub/gnu/gcc/
+   9. ftp://gcc.gnu.org/pub/gcc/releases/index.html
+  10. http://www.gnu.org/order/ftp.html
+  11. http://gcc.gnu.org/mirrors.html
+  12. http://gcc.gnu.org/index.html
+  13. mailto:gcc@gcc.gnu.org
+  14. http://gcc.gnu.org/about.html
+======================================================================
+http://gcc.gnu.org/gcc-2.95/gcc-2.95.1.html
+
+                                 GCC 2.95.1
+
+   August 19, 1999
+
+   The GNU project and the GCC/EGCS developers are pleased to announce
+   the release of GCC version 2.95.1. GCC used to stand for the GNU C
+   Compiler, but since the compiler supports several other languages
+   aside from C, it now stands for the GNU Compiler Collection.
+
+   This is a minor release to address several bugs in the GCC version
+   2.95 release.
+
+     * Generic bugfixes and improvements
+          + Various documentation fixes related to the GCC/EGCS merger.
+          + Fix memory management bug which could lead to spurious
+            aborts, core dumps or random parsing errors in the compiler.
+          + Fix a couple bugs in the dwarf1 and dwarf2 debug record
+            support.
+          + Fix infinite loop in the CSE optimizer.
+          + Avoid undefined behavior in compiler FP emulation code
+          + Fix install problem when prefix is overridden on the make
+            install command.
+          + Fix problem with unwanted installation of assert.h on some
+            systems.
+          + Fix problem with finding the wrong assembler in a single tree
+            build.
+          + Avoid increasing the known alignment of a register that is
+            already known to be a pointer.
+     * Platform specific bugfixes and improvements
+          + Codegen bugfix for prologue/epilogue for cpu32 target.
+          + Fix long long code generation bug for the Coldfire target.
+          + Fix various aborts in the SH compiler.
+          + Fix bugs in libgcc support library for the SH.
+          + Fix alpha ev6 code generation bug.
+          + Fix problems with EXIT_SUCCESS/EXIT_FAILURE redefinitions on
+            AIX platforms.
+          + Fix -fpic code generation bug for rs6000/ppc svr4 targets.
+          + Fix varargs/stdarg code generation bug for rs6000/ppc svr4
+            targets.
+          + Fix weak symbol handling for rs6000/ppc svr4 targets.
+          + Fix various problems with 64bit code generation for the
+            rs6000/ppc port.
+          + Fix codegen bug which caused tetex to be mis-compiled on the
+            x86
+          + Fix compiler abort in new cfg code exposed by x86 port.
+          + Fix out of range array reference in code convert flat
+            registers to the x87 stacked FP register file.
+          + Fix minor vxworks configuration bug
+          + Fix return type of bsearch for SunOS 4.x.
+     * Language & Runtime specific fixes.
+          + The G++ signature extension has been deprecated. It will be
+            removed in the next major release of G++. Use of signatures
+            will result in a warning from the compiler.
+          + Several bugs relating to templates and namespaces were fixed.
+          + A bug that caused crashes when combining templates with -g on
+            DWARF1 platforms was fixed.
+          + Pointers-to-members, virtual functions, and multiple
+            inheritance should now work together correctly.
+          + Some code-generation bugs relating to function try blocks
+            were fixed.
+          + G++ is a little bit more lenient with certain archaic
+            constructs than in GCC 2.95.
+          + Fix to prevent shared library version #s from bring truncated
+            to 1 digit
+          + Fix missing std:: in the libstdc++ library.
+          + Fix stream locking problems in libio.
+          + Fix problem in java compiler driver.
+
+   The whole suite has been extensively [1]regression tested and
+   [2]package tested. It should be reliable and suitable for widespread
+   use.
+
+   The compiler has several new optimizations, new targets, new languages
+   and other new features. See the [3]new features page for a more
+   complete list of new features found in the GCC 2.95 releases.
+
+   The sources include installation instructions in both HTML and
+   plaintext forms in the install directory in the distribution. However,
+   the most up to date [4]installation instructions and [5]build/test
+   status are on the web pages. We will update those pages as new
+   information becomes available.
+
+   The GCC developers would like to thank the numerous people that have
+   contributed new features, test results, bugfixes, etc to GCC. This
+   [6]amazing group of volunteers is what makes GCC successful.
+
+   And finally, we can't in good conscience fail to mention some
+   [7]caveats to using GCC 2.95.1.
+
+   Download GCC 2.95.1 from the [8]GNU FTP server (ftp://ftp.gnu.org)
+   Download GCC 2.95.1 from the [9]GCC/EGCS FTP server
+   (ftp://go.cygnus.com)
+   [10]Find a GNU mirror site
+   [11]Find a GCC/EGCS mirror site
+
+   For additional information about GCC please see the [12]GCC project
+   web server or contact the [13]GCC development mailing list.
+     _________________________________________________________________
+
+
+    [14]The GCC team
+    Last modified 2000-11-10
+
+References
+
+   1. http://gcc.gnu.org/gcc-2.95/regress.html
+   2. http://gcc.gnu.org/gcc-2.95/othertest.html
+   3. http://gcc.gnu.org/gcc-2.95/features.html
+   4. http://gcc.gnu.org/install/index.html
+   5. http://gcc.gnu.org/gcc-2.95/buildstat.html
+   6. http://gcc.gnu.org/thanks.html
+   7. http://gcc.gnu.org/gcc-2.95/caveats.html
+   8. ftp://ftp.gnu.org/pub/gnu/gcc/
+   9. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+  10. http://www.gnu.org/order/ftp.html
+  11. http://gcc.gnu.org/mirrors.html
+  12. http://gcc.gnu.org/index.html
+  13. mailto:gcc@gcc.gnu.org
+  14. http://gcc.gnu.org/about.html
+======================================================================
+http://gcc.gnu.org/gcc-2.95/gcc-2.95.html
+
+                                  GCC 2.95
+
+   July 31, 1999
+
+   The GNU project and the GCC/EGCS developers are pleased to announce
+   the release of GCC version 2.95. GCC used to stand for the GNU C
+   Compiler, but since the compiler supports several other languages
+   aside from C, it now stands for the GNU Compiler Collection.
+
+   This is the first release of GCC since the April 1999 GCC/EGCS
+   reunification and includes nearly a year's worth of new development
+   and bugfixes.
+
+   The whole suite has been extensively [1]regression tested and
+   [2]package tested. It should be reliable and suitable for widespread
+   use.
+
+   The compiler has several new optimizations, new targets, new languages
+   and other new features. See the [3]new features page for a more
+   complete list of new features found in the GCC 2.95 releases.
+
+   The sources include installation instructions in both HTML and
+   plaintext forms in the install directory in the distribution. However,
+   the most up to date [4]installation instructions and [5]build/test
+   status are on the web pages. We will update those pages as new
+   information becomes available.
+
+   The GCC developers would like to thank the numerous people that have
+   contributed new features, test results, bugfixes, etc to GCC. This
+   [6]amazing group of volunteers is what makes GCC successful.
+
+   And finally, we can't in good conscience fail to mention some
+   [7]caveats to using GCC 2.95.
+
+   Download GCC 2.95 from the [8]GNU FTP server (ftp://ftp.gnu.org)
+   Download GCC 2.95 from the [9]GCC/EGCS FTP server
+   (ftp://go.cygnus.com)
+   [10]Find a GNU mirror site
+   [11]Find a GCC/EGCS mirror site
+
+   For additional information about GCC please see the [12]GCC project
+   web server or contact the [13]GCC development mailing list.
+     _________________________________________________________________
+
+
+    [14]The GCC team
+    Last modified 2000-11-10
+
+References
+
+   1. http://gcc.gnu.org/gcc-2.95/regress.html
+   2. http://gcc.gnu.org/gcc-2.95/othertest.html
+   3. http://gcc.gnu.org/gcc-2.95/features.html
+   4. http://gcc.gnu.org/install/index.html
+   5. http://gcc.gnu.org/gcc-2.95/buildstat.html
+   6. http://gcc.gnu.org/thanks.html
+   7. http://gcc.gnu.org/gcc-2.95/caveats.html
+   8. ftp://ftp.gnu.org/pub/gnu/gcc/
+   9. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+  10. http://www.gnu.org/order/ftp.html
+  11. http://gcc.gnu.org/mirrors.html
+  12. http://gcc.gnu.org/index.html
+  13. mailto:gcc@gcc.gnu.org
+  14. http://gcc.gnu.org/about.html
+======================================================================
+http://gcc.gnu.org/gcc-2.95/features.html
+
+                           GCC 2.95 New Features
+
+     * General Optimizer Improvements:
+          + [1]Localized register spilling to improve speed and code
+            density especially on small register class machines.
+          + [2]Global CSE using lazy code motion algorithms.
+          + [3]Improved global constant/copy propagation.
+          + [4]Improved control flow graph analysis and manipulation.
+          + [5]Local dead store elimination.
+          + [6]Memory Load hoisting/store sinking in loops.
+          + [7]Type based alias analysis is enabled by default. Note this
+            feature will expose bugs in the Linux kernel. Please refer to
+            the [8]FAQ for additional information on this issue.
+          + Major revamp of GIV detection, combination and simplification
+            to improve loop performance.
+          + Major improvements to register allocation and reloading.
+     * New Languages and Language specific improvements
+          + [9]Many C++ improvements.
+          + [10]Many Fortran improvements.
+          + [11]Java front-end has been integrated. A [12]runtime library
+            is available separately.
+          + [13]ISO C99 support
+          + [14]Chill front-end and runtime has been integrated.
+          + Boehm garbage collector support in libobjc.
+          + More support for various pragmas which appear in vendor
+            include files
+     * New Targets and Target Specific Improvements
+          + [15]Sparc backend rewrite.
+          + -mschedule=8000 will optimize code for PA8000 class
+            processors; -mpa-risc-2-0 will generate code for PA2.0
+            processors
+          + Various micro-optimizations for the ia32 port. K6
+            optimizations
+          + Compiler will attempt to align doubles in the stack on the
+            ia32 port
+          + Alpha EV6 support
+          + PowerPC 750
+          + RS6000/PowerPC: -mcpu=401 was added as an alias for
+            -mcpu=403. -mcpu=e603e was added to do -mcpu=603e and
+            -msoft-float.
+          + c3x, c4x
+          + HyperSparc
+          + SparcLite86x
+          + sh4
+          + Support for new systems (OpenBSD, FreeBSD, UWIN, Interix,
+            arm-linux)
+          + vxWorks targets include support for vxWorks threads
+          + StrongARM 110 and ARM9 support added. ARM Scheduling
+            parameters rewritten.
+          + Various changes to the MIPS port to avoid assembler macros,
+            which
+          + Various performance improvements to the i960 port.
+          + Major rewrite of ns32k port in turn improves performance
+     * Other significant improvements
+          + [16]Ability to dump cfg information and display it using vcg.
+          + The new faster scheme for fixing vendor header files is
+            enabled by default.
+          + Experimental internationalization support.
+          + multibyte character support
+          + Some compile-time speedups for pathological problems
+          + Better support for complex types
+     * Plus the usual mountain of bugfixes
+     * Core compiler is based on the gcc2 development tree from Sept 30,
+       1998, so we have all of the [17]features found in GCC 2.8.
+     _________________________________________________________________
+
+
+    [18]The GCC team
+    Last modified 2000-12-04
+
+References
+
+   1. http://gcc.gnu.org/news/spill.html
+   2. http://gcc.gnu.org/news/lcm.html
+   3. http://gcc.gnu.org/news/cprop.html
+   4. http://gcc.gnu.org/news/cfg.html
+   5. http://gcc.gnu.org/news/dse.html
+   6. http://gcc.gnu.org/news/hoist.html
+   7. http://gcc.gnu.org/news/alias.html
+   8. http://gcc.gnu.org/fom_serv/cache/24.html
+   9. http://gcc.gnu.org/gcc-2.95/c++features.html
+  10. http://gcc.gnu.org/onlinedocs/g77_news.html
+  11. http://sources.redhat.com/java/gcj-announce.txt
+  12. http://gcc.gnu.org/javaannounce.html
+  13. http://gcc.gnu.org/c99status.html
+  14. http://gcc.gnu.org/news/chill.html
+  15. http://gcc.gnu.org/news/sparc.html
+  16. http://gcc.gnu.org/news/egcs-vcg.html
+  17. http://gcc.gnu.org/egcs-1.0/features-2.8.html
+  18. http://gcc.gnu.org/about.html
+======================================================================
+http://gcc.gnu.org/gcc-2.95/caveats.html
+
+                              GCC 2.95 Caveats
+
+     * GCC 2.95 will issue an error for invalid asm statements that had
+       been silently accepted by earlier versions of the compiler. This
+       is particularly noticeable when compiling older versions of the
+       Linux kernel (2.0.xx). Please refer to the [1]FAQ for more
+       information on this issue.
+     * GCC 2.95 implements type based alias analysis to disambiguate
+       memory references. Some programs, particularly the Linux kernel
+       violate ANSI/ISO aliasing rules and therefore may not operate
+       correctly when compiled with GCC 2.95. Please refer to the [2]FAQ
+       for more information on this issue.
+     * GCC 2.95 has a known bug in its handling of complex variables for
+       64bit targets. Instead of silently generating incorrect code, GCC
+       2.95 will issue a fatal error for situations it can not handle.
+       This primarily affects the Fortran community as Fortran makes more
+       use of complex variables than C or C++.
+     * GCC 2.95 has an integrated libstdc++, but does not have an
+       integrated libg++. Furthermore old libg++ releases will not work
+       with GCC 2.95. You can retrieve a recent copy of libg++ from the
+       [3]GCC ftp server.
+       Note most C++ programs only need libstdc++.
+     * Exception handling may not work with shared libraries,
+       particularly on alphas, hppas, rs6000/powerpc and mips based
+       platforms. Exception handling is known to work on x86 GNU/Linux
+       platforms with shared libraries.
+     * In general, GCC 2.95 is more rigorous about rejecting invalid C++
+       code or deprecated C++ constructs than G++ 2.7, G++ 2.8, EGCS 1.0,
+       or EGCS 1.1. As a result it may be necessary to fix C++ code
+       before it will compile with GCC 2.95.
+     * G++ is also converting toward the ISO C++ standard; as a result
+       code which was previously valid (and thus accepted by other
+       compilers and older versions of g++) may no longer be accepted.
+       The flag -fpermissive may allow some non-conforming code to
+       compile with GCC 2.95.
+     * GCC 2.95 compiled C++ code is not binary compatible with EGCS
+       1.1.x, EGCS 1.0.x or GCC 2.8.x.
+     * GCC 2.95 does not have changes from the GCC 2.8 tree that were
+       made between Sept 30, 1998 and April 30, 1999 (the official end of
+       the GCC 2.8 project). Future GCC releases will include all the
+       changes from the defunct GCC 2.8 sources.
+     _________________________________________________________________
+
+
+    [4]The GCC team
+    Last modified 2000-11-10
+
+References
+
+   1. http://gcc.gnu.org/faq.html#asmclobber
+   2. http://gcc.gnu.org/fom_serv/cache/24.html
+   3. ftp://gcc.gnu.org/pub/gcc/infrastructure/libg++-2.8.1.3.tar.gz
+   4. http://gcc.gnu.org/about.html
+======================================================================
+http://gcc.gnu.org/egcs-1.1/egcs-1.1.2.html
+
+                                 EGCS 1.1.2
+
+   March 15, 1999
+
+   We are pleased to announce the release of EGCS 1.1.2.
+
+   EGCS is a collaborative effort involving several groups of hackers
+   using an open development model to accelerate development and testing
+   of GNU compilers and runtime libraries.
+
+   EGCS 1.1.2 is a minor update to the EGCS 1.1.1 compiler to fix several
+   serious problems in EGCS 1.1.1.
+     * General improvements and fixes
+          + Fix bug in loop optimizer which caused the SPARC (and
+            potentially other) ports to segfault.
+          + Fix infinite recursion in alias analysis and combiner code.
+          + Fix bug in regclass preferencing.
+          + Fix incorrect loop reversal which caused incorrect code to be
+            generated for several targets.
+          + Fix return value for builtin memcpy.
+          + Reduce compile time for certain loops which exposed quadratic
+            behavior in the loop optimizer.
+          + Fix bug which caused volatile memory to be written multiple
+            times when only one write was needed/desired.
+          + Fix compiler abort in caller-save.c
+          + Fix combiner bug which caused incorrect code generation for
+            certain division by constant operations.
+          + Fix incorrect code generation due to a bug in range check
+            optimizations.
+          + Fix incorrect code generation due to mis-handling of
+            clobbered values in CSE.
+          + Fix compiler abort/segfault due to incorrect register
+            splitting when unrolling loops.
+          + Fix code generation involving autoincremented addresses with
+            ternary operators.
+          + Work around bug in the scheduler which caused qt to be
+            mis-compiled on some platforms.
+          + Fix code generation problems with -fshort-enums.
+          + Tighten security for temporary files.
+          + Improve compile time for codes which make heavy use of
+            overloaded functions.
+          + Fix multiply defined constructor/destructor symbol problems.
+          + Avoid setting bogus RPATH environemnt variable during
+            bootstrap.
+          + Avoid GNU-make dependencies in the texinfo subdir.
+          + Install CPP wrapper script in $(prefix)/bin if --enable-cpp.
+            --enable-cpp= can be used to specify an additional install
+            directory for the cpp wrapper script.
+          + Fix CSE bug which caused incorrect label-label refs to appear
+            on some platforms.
+          + Avoid linking in EH routines from libgcc if they are not
+            needed.
+          + Avoid obscure bug in aliasing code.
+          + Fix bug in weak symbol handling.
+     * Platform-specific improvements and fixes
+          + Fix detection of PPro/PII on Unixware 7.
+          + Fix compiler segfault when building spec99 and other programs
+            for SPARC targets.
+          + Fix code-generation bugs for integer and floating point
+            conditional move instructions on the PPro/PII.
+          + Use fixincludes to fix byteorder problems on i?86-*-sysv.
+          + Fix build failure for the arc port.
+          + Fix floating point format configuration for i?86-gnu port
+          + Fix problems with hppa1.0-hp-hpux10.20 configuration when
+            threads are enabled
+          + Fix coldfire code generation bugs.
+          + Fix "unrecognized insn" problems for Alpha and PPC ports.
+          + Fix h8/300 code generation problem with floating point values
+            in memory.
+          + Fix unrecognized insn problems for the m68k port.
+          + Fix namespace-pollution problem for the x86 port.
+          + Fix problems with old assembler on x86 NeXT systems.
+          + Fix PIC code-generation problems for the SPARC port.
+          + Fix minor bug with LONG_CALLS in PowerPC SVR4 support.
+          + Fix minor ISO namespace violation in Alpha varargs/stdarg
+            support.
+          + Fix incorrect "braf" instruction usage for the SH port.
+          + Fix minor bug in va-sh which prevented its use with -ansi.
+          + Fix problems recognizing and supporting FreeBSD.
+          + Handle OpenBSD systems correctly.
+          + Minor fixincludes fix for Digital UNIX 4.0B.
+          + Fix problems with ctors/dtors in SCO shared libraries.
+          + Abort instead of generating incorrect code for PPro/PII
+            floating point conditional moves.
+          + Avoid multiply defined symbols on Linux/GNU systems using
+            libc-5.4.xx.
+          + Fix abort in alpha compiler.
+
+     Fortran-specific fixes
+     * Fix the IDate intrinsic (VXT) (in libg2c) so the returned year is
+       in the documented, non-Y2K-compliant range of 0-99, instead of
+       being returned as 100 in the year 2000.
+     * Fix the `Date_and_Time' intrinsic (in libg2c) to return the
+       milliseconds value properly in Values(8).
+     * Fix the `LStat' intrinsic (in libg2c) to return device-ID
+       information properly in SArray(7).
+
+   An important goal of EGCS is to allow wide scale testing of new
+   features and optimizations which are still under development. However,
+   EGCS has been carefully tested and should be comparable in quality to
+   most gcc releases.
+
+   EGCS 1.1.2 is based on the June 6, 1998 snapshot of the GCC 2.8
+   development sources; it contains all of the new features found in GCC
+   2.8.1 as well as all new development from gcc2 up to June 6, 1998.
+
+   See the [1]new features page for a more complete list of new features
+   found in EGCS 1.1 releases.
+
+   The EGCS 1.1.2 release includes installation instructions in both HTML
+   and plaintext forms (see the INSTALL directory in the toplevel
+   directory of the EGCS 1.1.2 distribution). However, we also keep the
+   most up to date [2]installation instructions and [3]build/test status
+   on our web page. We will update those pages as new information becomes
+   available.
+
+   The EGCS project would like to thank the numerous people that have
+   contributed new features, test results, bugfixes, etc. This [4]amazing
+   group of volunteers is what makes EGCS successful.
+
+   And finally, we can't in good conscience fail to mention some
+   [5]caveats to using EGCS 1.1.2. [6]Download EGCS 1.1.2 from
+   egcs.cygnus.com (USA California) -->
+
+   [7]Download EGCS 1.1.2 from go.cygnus.com (USA California - High speed
+   link provided by Stanford)
+
+   The EGCS 1.1.2 release is also available on many [8]mirror sites.
+     _________________________________________________________________
+
+   Last modified on July 28, 1999.
+
+References
+
+   1. http://gcc.gnu.org/egcs-1.1/features.html
+   2. http://gcc.gnu.org/install/index.html
+   3. http://gcc.gnu.org/egcs-1.1/buildstat.html
+   4. http://gcc.gnu.org/thanks.html
+   5. http://gcc.gnu.org/egcs-1.1/caveats.html
+   6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+   7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+   8. http://gcc.gnu.org/mirrors.html
+======================================================================
+http://gcc.gnu.org/egcs-1.1/egcs-1.1.1.html
+
+                                 EGCS 1.1.1
+
+   December 1, 1998
+
+   We are pleased to announce the release of EGCS 1.1.1.
+
+   EGCS is a collaborative effort involving several groups of hackers
+   using an open development model to accelerate development and testing
+   of GNU compilers and runtime libraries.
+
+   EGCS 1.1.1 is a minor update to the EGCS 1.1 compiler to fix several
+   serious problems in EGCS 1.1.
+     * General improvements and fixes
+          + Avoid some stack overflows when compiling large functions.
+          + Avoid incorrect loop invariant code motions.
+          + Fix some core dumps on Linux kernel code.
+          + Bring back the imake -Di386 and friends fix from EGCS 1.0.2.
+          + Fix code generation problem in gcse.
+          + Various documentation related fixes.
+     * g++/libstdc++ improvements and fixes
+          + MT safe EH fix for setjmp/longjmp based exception handling.
+          + Fix a few bad interactions between optimization and exception
+            handling.
+          + Fixes for demangling of template names starting with "__".
+          + Fix a bug that would fail to run destructors in some cases
+            with -O2.
+          + Fix 'new' of classes with virtual bases.
+          + Fix crash building Qt on the Alpha.
+          + Fix failure compiling WIFEXITED macro on GNU/Linux.
+          + Fix some -frepo failures.
+     * g77 and libf2c improvements and fixes
+          + Various documentation fixes.
+          + Avoid compiler crash on RAND intrinsic.
+          + Fix minor bugs in makefiles exposed by BSD make programs.
+          + Define _XOPEN_SOURCE for libI77 build to avoid potential
+            problems on some 64-bit systems.
+          + Fix problem with implicit endfile on rewind.
+          + Fix spurious recursive I/O errors.
+     * platform specific improvements and fixes
+          + Match all versions of UnixWare7.
+          + Do not assume x86 SVR4 or UnixWare targets can handle stabs
+          + Fix PPC/RS6000 LEGITIMIZE_ADDRESS macro and bug in conversion
+            from unsigned ints to double precision floats.
+          + Fix ARM ABI issue with NetBSD.
+          + Fix a few arm code generation bugs.
+          + Fixincludes will fix additional broken SCO OpenServer header
+            files.
+          + Fix a m68k backend bug which caused invalid offsets in reg+d
+            addresses.
+          + Fix problems with 64bit AIX 4.3 support.
+          + Fix handling of long longs for varargs/stdarg functions on
+            the ppc.
+          + Minor fixes to CPP predefines for Windows.
+          + Fix code generation problems with gpr<->fpr copies for 64bit
+            ppc
+          + Fix a few coldfire code generation bugs.
+          + Fix some more header file problems on SunOS 4.x
+          + Fix assert.h handling for RTEMS.
+          + Fix Windows handling of TREE_SYMBOL_REFERENCED.
+          + Fix x86 compiler abort in reg-stack pass.
+          + Fix cygwin/windows problem with section attributes.
+          + Fix Alpha code generation problem exposed by SMP Linux
+            kernels.
+          + Fix typo in m68k 32->64bit integer conversion.
+          + Make sure target libraries build with -fPIC for PPC & Alpha
+            targets.
+
+   An important goal of EGCS is to allow wide scale testing of new
+   features and optimizations which are still under development. However,
+   EGCS has been carefully tested and should be comparable in quality to
+   most gcc releases.
+
+   EGCS 1.1.1 is based on the June 6, 1998 snapshot of the GCC 2.8
+   development sources; it contains all of the new features found in GCC
+   2.8.1 as well as all new development from gcc2 up to June 6, 1998.
+
+   See the [1]new features page for a more complete list of new features
+   found in EGCS 1.1 releases.
+
+   The EGCS 1.1.1 release includes installation instructions in both HTML
+   and plaintext forms (see the INSTALL directory in the toplevel
+   directory of the EGCS 1.1.1 distribution). However, we also keep the
+   most up to date [2]installation instructions and [3]build/test status
+   on our web page. We will update those pages as new information becomes
+   available.
+
+   The EGCS project would like to thank the numerous people that have
+   contributed new features, test results, bugfixes, etc. This [4]amazing
+   group of volunteers is what makes EGCS successful.
+
+   And finally, we can't in good conscience fail to mention some
+   [5]caveats to using EGCS 1.1.1.
+
+   [6]Download EGCS 1.1.1 from egcs.cygnus.com (USA California)
+
+   The EGCS 1.1.1 release is also available on many mirror sites.
+   [7]Goto mirror list to find a closer site
+     _________________________________________________________________
+
+   Last modified on July 28, 1999.
+
+References
+
+   1. http://gcc.gnu.org/egcs-1.1/features.html
+   2. http://gcc.gnu.org/install/index.html
+   3. http://gcc.gnu.org/egcs-1.1/buildstat.html
+   4. http://gcc.gnu.org/thanks.html
+   5. http://gcc.gnu.org/egcs-1.1/caveats.html
+   6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+   7. http://gcc.gnu.org/mirrors.html
+======================================================================
+http://gcc.gnu.org/egcs-1.1/egcs-1.1.html
+
+                                  EGCS 1.1
+
+   September 3, 1998
+
+   We are pleased to announce the release of EGCS 1.1.
+
+   EGCS is a free software project to further the development of the GNU
+   compilers using an open development environment.
+
+   EGCS 1.1 is a major new release of the EGCS compiler system. It has
+   been [1]extensively tested and is believed to be stable and suitable
+   for widespread use.
+
+   EGCS 1.1 is based on an June 6, 1998 snapshot of the GCC 2.8
+   development sources; it contains all of the new features found in GCC
+   2.8.1 as well as all new development from GCC up to June 6, 1998.
+
+   EGCS also contains many improvements and features not found in GCC or
+   in older versions of EGCS.
+     * Global common subexpression elimination and global constant/copy
+       propagation (aka [2]gcse)
+     * Ongoing improvements to the [3]alias analysis support to allow for
+       better optimizations throughout the compiler.
+     * Vastly improved [4]C++ compiler and integrated C++ runtime
+       libraries.
+     * Fixes for the /tmp symlink race security problems.
+     * New targets including mips16, arm-thumb and 64 bit PowerPC.
+     * Improvements to GNU Fortran (g77) compiler and runtime library
+       made since [5]g77 version 0.5.23.
+
+   See the [6]new features page for a more complete list of new features
+   found in EGCS 1.1 releases.
+
+   The EGCS 1.1 release includes installation instructions in both HTML
+   and plaintext forms (see the INSTALL directory in the toplevel
+   directory of the EGCS 1.1 distribution). However, we also keep the
+   most up to date [7]installation instructions and [8]build/test status
+   on our web page. We will update those pages as new information becomes
+   available.
+
+   The EGCS project would like to thank the numerous people that have
+   contributed new features, test results, bugfixes, etc. This [9]amazing
+   group of volunteers is what makes EGCS successful.
+
+   And finally, we can't in good conscience fail to mention some
+   [10]caveats to using EGCS 1.1.
+
+   [11]Download EGCS 1.1 from egcs.cygnus.com (USA California)
+
+   [12]Download EGCS 1.1 from go.cygnus.com (USA California -- High speed
+   link provided by Stanford)
+
+   The EGCS 1.1 release is also available on many mirror sites.
+   [13]Goto mirror list to find a closer site
+     _________________________________________________________________
+
+   Last modified on September 4, 1999.
+
+References
+
+   1. http://gcc.gnu.org/egcs-1.1/egcs-1.1-test.html
+   2. http://gcc.gnu.org/news/gcse.html
+   3. http://gcc.gnu.org/news/alias.html
+   4. http://gcc.gnu.org/egcs-1.1/c++features.html
+   5. http://gcc.gnu.org/onlinedocs/g77_news.html
+   6. http://gcc.gnu.org/egcs-1.1/features.html
+   7. http://gcc.gnu.org/install/index.html
+   8. http://gcc.gnu.org/egcs-1.1/buildstat.html
+   9. http://gcc.gnu.org/thanks.html
+  10. http://gcc.gnu.org/egcs-1.1/caveats.html
+  11. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+  12. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+  13. http://gcc.gnu.org/mirrors.html
+======================================================================
+http://gcc.gnu.org/egcs-1.1/features.html
+
+                           EGCS 1.1 new features
+
+     * Integrated GNU Fortran (g77) compiler and runtime library with
+       improvements, based on [1]g77 version 0.5.23.
+     * Vast improvements in the C++ compiler; so many they have [2]page
+       of their own!
+     * Compiler implements [3]global common subexpression elimination and
+       global copy/constant propagation.
+     * More major improvements in the [4]alias analysis code.
+     * More major improvements in the exception handling code to improve
+       performance, lower static overhead and provide the infrastructure
+       for future improvements.
+     * The infamous /tmp symlink race security problems have been fixed.
+     * The regmove optimization pass has been nearly completely rewritten
+       to improve performance of generated code.
+     * The compiler now recomputes register usage information before
+       local register allocation. By providing more accurate information
+       to the priority based allocator, we get better register
+       allocation.
+     * The register reloading phase of the compiler optimizes spill code
+       much better than in previous releases.
+     * Some bad interactions between the register allocator and
+       instruction scheduler have been fixed, resulting in much better
+       code for certain programs. Additionally, we have tuned the
+       scheduler in various ways to improve performance of generated code
+       for some architectures.
+     * The compiler's branch shortening algorithms have been
+       significantly improved to work better on targets which align jump
+       targets.
+     * The compiler now supports -Os to prefer optimizing for code space
+       over optimizing for code speed.
+     * The compiler will now totally eliminate library calls which
+       compute constant values. This primarily helps targets with no
+       integer div/mul support and targets without floating point
+       support.
+     * The compiler now supports an extensive "--help" option.
+     * cpplib has been greatly improved and may be suitable for limited
+       use.
+     * Memory footprint for the compiler has been significantly reduced
+       for some pathological cases.
+     * The time to build EGCS has been improved for certain targets
+       (particularly the alpha and mips platforms).
+     * Many infrastructure improvements throughout the compiler, plus the
+       usual mountain of bugfixes and minor improvements.
+     * Target dependent improvements:
+          + SPARC port now includes V8 plus and V9 support as well as
+            performance tuning for Ultra class machines. The SPARC port
+            now uses the Haifa scheduler.
+          + Alpha port has been tuned for the EV6 processor and has an
+            optimized expansion of memcpy/bzero. The Alpha port now uses
+            the Haifa scheduler.
+          + RS6000/PowerPC: EGCS 1.1 includes support for the Power64
+            architecture and aix4.3 support. The RS6000/PowerPC port now
+            uses the Haifa scheduler.
+          + x86: Alignment of static store data and jump targets is per
+            Intel recommendations now. Various improvements throughout
+            the x86 port to improve performance on Pentium processors.
+            Conditional move support has been fixed and enabled for PPro
+            processors. The x86 port also better supports 64bit
+            operations now.
+          + MIPS has improved multiply/multiply-add support and now
+            includes mips16 ISA support.
+          + M68k has many micro-optimizations and Coldfire fixes.
+     * Core compiler is based on the GCC development tree from June 9,
+       1998, so we have all of the [5]features found in GCC 2.8.
+
+   [6]Return to the EGCS home page
+
+   Last modified: September 4, 1999
+
+References
+
+   1. http://gcc.gnu.org/onlinedocs/g77_news.html
+   2. http://gcc.gnu.org/egcs-1.1/c++features.html
+   3. http://gcc.gnu.org/news/gcse.html
+   4. http://gcc.gnu.org/news/alias.html
+   5. http://gcc.gnu.org/egcs-1.0/features-2.8.html
+   6. http://gcc.gnu.org/index.html
+======================================================================
+http://gcc.gnu.org/egcs-1.1/caveats.html
+
+                              EGCS 1.1 Caveats
+
+     * EGCS has an integrated libstdc++, but does not have an integrated
+       libg++. Furthermore old libg++ releases will not work with EGCS;
+       HJ Lu has made a [1]libg++ snapshot available which may work with
+       EGCS.
+       Note most C++ programs only need libstdc++.
+     * Exception handling may not work with shared libraries,
+       particularly on alphas, hppas, rs6000/powerpc and mips based
+       platforms. Exception handling is known to work on x86-linux
+       platforms with shared libraries.
+     * Some versions of the Linux kernel have bugs which prevent them
+       from being compiled or from running when compiled by EGCS. See
+       [2]the FAQ for additional information.
+     * In general, EGCS is more rigorous about rejecting invalid C++ code
+       or deprecated C++ constructs than g++-2.7, g++-2.8 or EGCS 1.0. As
+       a result it may be necessary to fix C++ code before it will
+       compile with EGCS.
+     * G++ is also converting toward the ISO C++ standard; as a result
+       code which was previously valid (and thus accepted by other
+       compilers and older versions of g++) may no longer be accepted.
+     * EGCS 1.1 compiled C++ code is not binary compatible with EGCS
+       1.0.x or GCC 2.8.x due to changes necessary to support thread safe
+       exception handling.
+
+   [3]Return to the GCC home page
+
+   Last modified: July 28, 1999
+
+References
+
+   1. ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1.2.tar.gz
+   2. http://gcc.gnu.org/fom_serv/cache/24.html
+   3. http://gcc.gnu.org/index.html
+======================================================================
+http://gcc.gnu.org/egcs-1.0/egcs-1.0.3.html
+
+                                 EGCS 1.0.3
+
+   May 15, 1998
+
+   We are pleased to announce the release of EGCS 1.0.3.
+
+   EGCS is a collaborative effort involving several groups of hackers
+   using an open development model to accelerate development and testing
+   of GNU compilers and runtime libraries.
+
+   EGCS 1.0.3 is a minor update to the EGCS 1.0.2 compiler to fix a few
+   problems reported by Red Hat for builds of Red Hat 5.1.
+     * Generic bugfixes:
+          + Fix a typo in the libio library which resulted in incorrect
+            behavior of istream::get.
+          + Fix the Fortran negative array index problem.
+          + Fix a major problem with the ObjC runtime thread support
+            exposed by glibc2.
+          + Reduce memory consumption of the Haifa scheduler.
+     * Target specific bugfixes:
+          + Fix one x86 floating point code generation bug exposed by
+            glibc2 builds.
+          + Fix one x86 internal compiler error exposed by glibc2 builds.
+          + Fix profiling bugs on the Alpha.
+          + Fix ImageMagick & emacs 20.2 build problems on the Alpha.
+          + Fix rs6000/ppc bug when converting values from integer types
+            to floating point types.
+
+   An important goal of EGCS is to allow wide scale testing of new
+   features and optimizations which are still under development. However,
+   EGCS has been carefully tested and should be comparable in quality to
+   most GCC releases.
+
+   EGCS 1.0.3 is based on an August 2, 1997 snapshot of the GCC 2.8
+   development sources; it contains nearly all of the new features found
+   in GCC 2.8.
+
+   EGCS also contains many improvements and features not found in GCC 2.7
+   or GCC 2.8.
+     * Integrated C++ runtime libraries, including support for most major
+       GNU/Linux systems!
+     * The integrated libstdc++ library includes a verbatim copy of
+       [1]SGI's STL release instead of a modified copy.
+     * Integrated GNU Fortran compiler
+     * New instruction scheduler
+     * New alias analysis code
+
+   See the [2]new features page for a more complete list of new features
+   found in EGCS 1.0.x releases.
+
+   The EGCS 1.0.3 release includes installation instructions in both HTML
+   and plaintext forms (see the INSTALL directory in the toplevel
+   directory of the EGCS 1.0.3 distribution). However, we also keep the
+   most up to date [3]installation instructions and [4]build/test status
+   on our web page. We will update those pages as new information becomes
+   available.
+
+   And, we can't in good conscience fail to mention some [5]caveats to
+   using EGCS.
+
+   Update: Big thanks to Stanford for providing a high speed link for
+   downloading EGCS (go.cygnus.com)!
+
+   [6]Download EGCS 1.0.3 from ftp.cygnus.com (USA California)
+
+   [7]Download EGCS 1.0.3 from go.cygnus.com (USA California -- High
+   speed link provided by Stanford)
+
+   The EGCS 1.0.3 release is also available on many mirror sites.
+   [8]Goto mirror list to find a closer site
+
+   We'd like to thank the numerous people that have contributed new
+   features, test results, bugfixes, etc. Unfortunately, they're far too
+   numerous to mention by name.
+     _________________________________________________________________
+
+   Last modified on February 22, 1999.
+
+References
+
+   1. http://www.sgi.com/Technology/STL
+   2. http://gcc.gnu.org/egcs-1.0/features.html
+   3. http://gcc.gnu.org/install/index.html
+   4. http://gcc.gnu.org/egcs-1.0/buildstat.html
+   5. http://gcc.gnu.org/egcs-1.0/caveats.html
+   6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+   7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+   8. http://gcc.gnu.org/mirrors.html
+======================================================================
+http://gcc.gnu.org/egcs-1.0/egcs-1.0.2.html
+
+                                 EGCS 1.0.2
+
+   March 16, 1998
+
+   We are pleased to announce the release of EGCS 1.0.2.
+
+   EGCS is a collaborative effort involving several groups of hackers
+   using an open development model to accelerate development and testing
+   of GNU compilers and runtime libraries.
+
+   EGCS 1.0.2 is a minor update to the EGCS 1.0.1 compiler to fix several
+   serious problems in EGCS 1.0.1.
+     * General improvements and fixes
+          + Memory consumption significantly reduced, especially for
+            templates and inline functions.
+          + Fix various problems with glibc2.1.
+          + Fix loop optimization bug exposed by rs6000/ppc port.
+          + Fix to avoid potential code generation problems in jump.c.
+          + Fix some undefined symbol problems in dwarf1 debug support.
+     * g++/libstdc++ improvements and fixes
+          + libstdc++ in the EGCS release has been updated and should be
+            link compatible with libstdc++-2.8.
+          + Various fixes in libio/libstdc++ to work better on Linux
+            systems.
+          + Fix problems with duplicate symbols on systems that do not
+            support weak symbols.
+          + Memory corruption bug and undefined symbols in bastring have
+            been fixed.
+          + Various exception handling fixes.
+          + Fix compiler abort for very long thunk names.
+     * g77 improvements and fixes
+          + Fix compiler crash for omitted bound in Fortran CASE
+            statement.
+          + Add missing entries to g77 lang-options.
+          + Fix problem with -fpedantic in the g77 compiler.
+          + Fix "backspace" problem with g77 on alphas.
+          + Fix x86 backend problem with Fortran literals and -fpic.
+          + Fix some of the problems with negative subscripts for g77 on
+            alphas.
+          + Fixes for Fortran builds on cygwin32/mingw32.
+     * platform specific improvements and fixes
+          + Fix long double problems on x86 (exposed by glibc)
+          + x86 ports define i386 again to keep imake happy.
+          + Fix exception handling support on NetBSD ports.
+          + Several changes to collect2 to fix many problems with AIX.
+          + Define __ELF__ for rs6000/linux.
+          + Fix -mcall-linux problem on rs6000/linux.
+          + Fix stdarg/vararg problem for rs6000/linux.
+          + Allow autoconf to select a proper install problem on AIX 3.1.
+          + m68k port support includes -mcpu32 option as well as cpu32
+            multilibs.
+          + Fix stdarg bug for irix6.
+          + Allow EGCS to build on irix5 without the gnu assembler.
+          + Fix problem with static linking on sco5.
+          + Fix bootstrap on sco5 with native compiler.
+          + Fix for abort building newlib on H8 target.
+          + Fix fixincludes handling of math.h on SunOS.
+          + Minor fix for motorola 3300 m68k systems.
+
+   An important goal of EGCS is to allow wide scale testing of new
+   features and optimizations which are still under development. However,
+   EGCS has been carefully tested and should be comparable in quality to
+   most GCC releases.
+
+   EGCS 1.0.2 is based on an August 2, 1997 snapshot of the GCC 2.8
+   development sources; it contains nearly all of the new features found
+   in GCC 2.8.
+
+   EGCS also contains many improvements and features not found in GCC 2.7
+   or GCC 2.8.
+     * Integrated C++ runtime libraries, including support for most major
+       linux systems!
+     * The integrated libstdc++ library includes a verbatim copy of
+       [1]SGI's STL release.
+     * Integrated GNU Fortran compiler
+     * New instruction scheduler
+     * New alias analysis code
+
+   See the [2]new features page for a more complete list of new features
+   found in EGCS 1.0.x releases.
+
+   The EGCS 1.0.2 release includes installation instructions in both HTML
+   and plaintext forms (see the INSTALL directory in the toplevel
+   directory of the EGCS 1.0.2 distribution). However, we also keep the
+   most up to date [3]installation instructions and [4]build/test status
+   on our web page. We will update those pages as new information becomes
+   available.
+
+   And, we can't in good conscience fail to mention some [5]caveats to
+   using EGCS.
+
+   Update: Big thanks to Stanford for providing a high speed link for
+   downloading EGCS (go.cygnus.com)!
+
+   [6]Download EGCS 1.0.2 from ftp.cygnus.com (USA California)
+
+   [7]Download EGCS 1.0.2 from go.cygnus.com (USA California -- High
+   speed link provided by Stanford)
+
+   The EGCS 1.0.2 release is also available on many mirror sites.
+   [8]Goto mirror list to find a closer site
+
+   We'd like to thank the numerous people that have contributed new
+   features, test results, bugfixes, etc. Unfortunately, they're far too
+   numerous to mention by name.
+     _________________________________________________________________
+
+   Last modified on July 28, 1999.
+
+References
+
+   1. http://www.sgi.com/Technology/STL/
+   2. http://gcc.gnu.org/egcs-1.0/features.html
+   3. http://gcc.gnu.org/install/index.html
+   4. http://gcc.gnu.org/egcs-1.0/buildstat.html
+   5. http://gcc.gnu.org/egcs-1.0/caveats.html
+   6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+   7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+   8. http://gcc.gnu.org/mirrors.html
+======================================================================
+http://gcc.gnu.org/egcs-1.0/egcs-1.0.1.html
+
+                                 EGCS 1.0.1
+
+   January 6, 1998
+
+   We are pleased to announce the release of EGCS 1.0.1.
+
+   EGCS is a collaborative effort involving several groups of hackers
+   using an open development model to accelerate development and testing
+   of GNU compilers and runtime libraries.
+
+   EGCS 1.0.1 is a minor update to the EGCS 1.0 compiler to fix a few
+   critical bugs and add support for Red Hat 5.0 Linux. Changes since the
+   EGCS 1.0 release:
+     * Add support for Red Hat 5.0 Linux and better support for Linux
+       systems using glibc2.
+       Many programs failed to link when compiled with EGCS 1.0 on Red
+       Hat 5.0 or on systems with newer versions of glibc2. EGCS 1.0.1
+       should fix these problems.
+     * Compatability with both EGCS 1.0 and GCC 2.8 libgcc exception
+       handling interfaces.
+       To avoid future compatibility problems, we strongly urge anyone
+       who is planning on distributing shared libraries that contain C++
+       code to upgrade to EGCS 1.0.1 first.
+       Soon after EGCS 1.0 was released, the GCC developers made some
+       incompatible changes in libgcc's exception handling interfaces.
+       These changes were needed to solve problems on some platforms.
+       This means that GCC 2.8.0, when released, will not be seamlessly
+       compatible with shared libraries built by EGCS 1.0. The reason is
+       that the libgcc.a in GCC 2.8.0 will not contain a function needed
+       by the old interface.
+       The result of this is that there may be compatibility problems
+       with shared libraries built by EGCS 1.0 when used with GCC 2.8.0.
+       With EGCS 1.0.1, generated code uses the new (GCC 2.8.0)
+       interface, and libgcc.a has the support routines for both the old
+       and the new interfaces (so EGCS 1.0.1 and EGCS 1.0 code can be
+       freely mixed, and EGCS 1.0.1 and GCC 2.8.0 code can be freely
+       mixed).
+       The maintainers of GCC 2.x have decided against including seamless
+       support for the old interface in 2.8.0, since it was never
+       "official", so to avoid future compatibility problems we recommend
+       against distributing any shared libraries built by EGCS 1.0 that
+       contain C++ code (upgrade to 1.0.1 and use that).
+     * Various bugfixes in the x86, hppa, mips, and rs6000/ppc backends.
+       The x86 changes fix code generation errors exposed when building
+       glibc2 and the Linux dynamic linker (ld.so).
+       The hppa change fixes a compiler abort when configured for use
+       with RTEMS.
+       The MIPS changes fix problems with the definition of LONG_MAX on
+       newer systems, allow for command line selection of the target ABI,
+       and fix one code generation problem.
+       The rs6000/ppc change fixes some problems with passing structures
+       to varargs/stdarg functions.
+     * A few machine independent bugfixes, mostly to fix code generation
+       errors when building Linux kernels or glibc.
+     * Fix a few critical exception handling and template bugs in the C++
+       compiler.
+     * Fix Fortran namelist bug on alphas.
+     * Fix build problems on x86-solaris systems.
+
+   An important goal of EGCS is to allow wide scale testing of new
+   features and optimizations which are still under development. However,
+   EGCS has been carefully tested and should be comparable in quality to
+   most GCC releases.
+
+   EGCS 1.0.1 is based on an August 2, 1997 snapshot of the GCC 2.8
+   development sources; it contains nearly all of the new features found
+   in GCC 2.8.
+
+   EGCS also contains many improvements and features not found in GCC 2.7
+   and even the soon to be released GCC 2.8 compilers.
+     * Integrated C++ runtime libraries, including support for most major
+       linux systems!
+     * The integrated libstdc++ library includes a verbatim copy of
+       [1]SGI's STL release.
+     * Integrated GNU Fortran compiler
+     * New instruction scheduler
+     * New alias analysis code
+
+   See the [2]new features page for a more complete list of new features
+   found in EGCS 1.0.x releases.
+
+   The EGCS 1.0.1 release includes installation instructions in both HTML
+   and plaintext forms (see the INSTALL directory in the toplevel
+   directory of the EGCS 1.0.1 distribution). However, we also keep the
+   most up to date [3]installation instructions and [4]build/test status
+   on our web page. We will update those pages as new information becomes
+   available.
+
+   And, we can't in good conscience fail to mention some [5]caveats to
+   using EGCS.
+
+   Update: Big thanks to Stanford for providing a high speed link for
+   downloading EGCS (go.cygnus.com)!
+
+   [6]Download EGCS 1.0.1 from ftp.cygnus.com (USA California)
+
+   [7]Download EGCS 1.0.1 from go.cygnus.com (USA California -- High
+   speed link provided by Stanford)
+
+   The EGCS 1.0.1 release is also available on many mirror sites.
+   [8]Goto mirror list to find a closer site
+
+   We'd like to thank the numerous people that have contributed new
+   features, test results, bugfixes, etc. Unfortunately, they're far too
+   numerous to mention by name.
+     _________________________________________________________________
+
+   Last modified on July 28, 1999.
+
+References
+
+   1. http://www.sgi.com/Technology/STL/
+   2. http://gcc.gnu.org/egcs-1.0/features.html
+   3. http://gcc.gnu.org/install/index.html
+   4. http://gcc.gnu.org/egcs-1.0/buildstat.html
+   5. http://gcc.gnu.org/egcs-1.0/caveats.html
+   6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+   7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+   8. http://gcc.gnu.org/mirrors.html
+======================================================================
+http://gcc.gnu.org/egcs-1.0/egcs-1.0.html
+
+                                  EGCS 1.0
+
+   December 3, 1997
+
+   We are pleased to announce the release of EGCS 1.0.
+
+   EGCS is a collaborative effort involving several groups of hackers
+   using an open development model to accelerate development and testing
+   of GNU compilers and runtime libraries.
+
+   An important goal of EGCS is to allow wide scale testing of
+   experimental features and optimizations; therefore, EGCS contains some
+   features and optimizations which are still under development. However,
+   EGCS has been carefully tested and should be comparable in quality to
+   most GCC releases.
+
+   EGCS 1.0 is based on an August 2, 1997 snapshot of the GCC 2.8
+   development sources; it contains nearly all of the new features found
+   in GCC 2.8.
+
+   EGCS 1.0 also contains many improvements and features not found in GCC
+   2.7 and even the soon to be released GCC 2.8 compilers.
+     * Integrated C++ runtime libraries, including support for most major
+       linux systems!
+     * The integrated libstdc++ library includes a verbatim copy of
+       [1]SGI's STL release.
+     * Integrated GNU Fortran compiler
+     * New instruction scheduler
+     * New alias analysis code
+
+   See the [2]new features page for a more complete list of new features.
+
+   The EGCS 1.0 release includes installation instructions in both HTML
+   and plaintext forms (see the INSTALL directory in the toplevel
+   directory of the EGCS 1.0 distribution). However, we also keep the
+   most up to date [3]installation instructions and [4]build/test status
+   on our web page. We will update those pages as new information becomes
+   available.
+
+   And, we can't in good conscience fail to mention some [5]caveats to
+   using EGCS.
+
+   Update: The T1 into our main California offices has been 100%
+   saturated since shortly after the release. We've added an EGCS 1.0
+   mirror at our Massachusetts office to help share the load. We also
+   encourage folks to use the many mirrors available throughout the
+   world.
+
+   Update: Big thanks to Stanford for providing a high speed link for
+   downloading EGCS! (go.cygnus.com)
+
+   [6]Download EGCS 1.0 from ftp.cygnus.com (USA California)
+
+   [7]Download EGCS 1.0 from go.cygnus.com (USA California -- High speed
+   link provided by Stanford)
+
+   The EGCS 1.0 release should be available on most mirror sites by now.
+   [8]Goto mirror list to find a closer site
+
+   We'd like to thank the numerous people that have contributed new
+   features, test results, bugfixes, etc. Unfortunately, they're far too
+   numerous to mention by name.
+     _________________________________________________________________
+
+   Last modified on July 28, 1999.
+
+References
+
+   1. http://www.sgi.com/Technology/STL
+   2. http://gcc.gnu.org/egcs-1.0/features.html
+   3. http://gcc.gnu.org/install/index.html
+   4. http://gcc.gnu.org/egcs-1.0/buildstat.html
+   5. http://gcc.gnu.org/egcs-1.0/caveats.html
+   6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html
+   7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html
+   8. http://gcc.gnu.org/mirrors.html
+======================================================================
+http://gcc.gnu.org/egcs-1.0/features.html
+
+                             EGCS 1.0 features
+
+     * Core compiler is based on the gcc2 development tree from Aug 2,
+       1997, so we have most of the [1]features found in GCC 2.8.
+     * Integrated GNU Fortran compiler based on g77-0.5.22-19970929.
+     * Vast improvements in the C++ compiler; so many they have [2]page
+       of their own!
+     * Integrated C++ runtime libraries, including support for most major
+       linux systems!
+     * New instruction scheduler from IBM Haifa which includes support
+       for function wide instruction scheduling as well as superscalar
+       scheduling.
+     * Significantly improved alias analysis code.
+     * Improved register allocation for two address machines.
+     * Significant code generation improvements for Fortran code on
+       Alphas
+     * Various optimizations from the g77 project as well as improved
+       loop optimizations.
+     * Dwarf2 debug format support for some targets.
+     * egcs libstdc++ includes the SGI STL implementation without
+       changes.
+     * As a result of these and other changes, egcs libstc++ is not
+       binary compatible with previous releases of libstdc++.
+     * Various new ports -- UltraSPARC, Irix6.2 & Irix6.3 support, The
+       SCO Openserver 5 family (5.0.{0,2,4} and Internet FastStart 1.0
+       and 1.1), Support for RTEMS on several embedded targets, Support
+       for arm-linux, Mitsubishi M32R, Hitachi H8/S, Matsushita MN102 and
+       MN103, NEC V850, Sparclet, Solaris & Linux on PowerPCs, etc.
+     * Integrated testsuites for gcc, g++, g77, libstdc++ and libio.
+     * RS6000/PowerPC ports generate code which can run on all
+       RS6000/PowerPC variants by default.
+     * -mcpu= and -march= switches for the x86 port to allow better
+       control over how the x86 port generates code.
+     * Includes the template repository patch (aka repo patch); note the
+       new template code makes repo obsolete for ELF systems using gnu-ld
+       such as Linux.
+     * Plus the usual assortment of bugfixes and improvements.
+
+   [3]Return to the egcs home page
+
+   Last modified: July 28, 1999
+
+References
+
+   1. http://gcc.gnu.org/egcs-1.0/features-2.8.html
+   2. http://gcc.gnu.org/egcs-1.0/c++features.html
+   3. http://gcc.gnu.org/index.html
+======================================================================
+http://gcc.gnu.org/egcs-1.0/caveats.html
+
+                              EGCS 1.0 Caveats
+
+     * EGCS has an integrated libstdc++, but does not have an integrated
+       libg++. Furthermore old libg++ releases will not work with egc; HJ
+       Lu has made a [1]libg++ snapshot available which may work with
+       EGCS.
+       Note most C++ programs only need libstdc++.
+     * Note that using -pedantic or -Wreturn-type can cause an explosion
+       in the amount of memory needed for template-heavy C++ code, such
+       as code that uses STL. Also note that -Wall includes
+       -Wreturn-type, so if you use -Wall you will need to specify
+       -Wno-return-type to turn it off.
+     * Exception handling may not work with shared libraries,
+       particularly on alphas, hppas, and mips based platforms. Exception
+       handling is known to work on x86-linux platforms with shared
+       libraries.
+     * Some versions of the Linux kernel have bugs which prevent them
+       from being compiled or from running when compiled by EGCS. See
+       [2]the FAQ for additional information.
+     * In general, EGCS is more rigorous about rejecting invalid C++ code
+       or deprecated C++ constructs than G++ 2.7. As a result it may be
+       necessary to fix C++ code before it will compile with EGCS.
+     * G++ is also aggressively tracking the C++ standard; as a result
+       code which was previously valid (and thus accepted by other
+       compilers and older versions of G++) may no longer be accepted.
+     * EGCS 1.0 may not work with Red Hat Linux 5.0 on all targets. EGCS
+       1.0.x and later releases should work with Red Hat Linux 5.0.
+
+   [3]Return to the GCC home page
+
+   Last modified: August 27, 1998
+
+References
+
+   1. ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1.2.tar.gz
+   2. http://gcc.gnu.org/fom_serv/cache/24.html
+   3. http://gcc.gnu.org/index.html
+======================================================================
diff --git a/gnu/egcs/gcc/ONEWS b/gnu/egcs/gcc/ONEWS
new file mode 100644
index 00000000000..427df254eb6
--- /dev/null
+++ b/gnu/egcs/gcc/ONEWS
@@ -0,0 +1,1071 @@
+Noteworthy changes in GCC after EGCS 1.1.
+-----------------------------------------
+
+Target specific NEWS
+
+    RS6000/PowerPC: -mcpu=401 was added as an alias for -mcpu=403.  -mcpu=e603e
+		    was added to do -mcpu=603e and -msoft-float.
+
+Noteworthy changes in GCC for EGCS 1.1.
+---------------------------------------
+
+The compiler now implements global common subexpression elimination (gcse) as
+well as global constant/copy propagation.  (link to gcse page).
+
+More major improvements have been made to the alias analysis code.  A new
+option to allow front-ends to provide alias information to the optimizers
+has also been added (-fstrict-aliasing).  -fstrict-aliasing is off by default
+now, but will be enabled by default in the future. (link to alias page)
+
+Major changes continue in the exception handling support.  This release
+includes some changes to reduce static overhead for exception handling.  It
+also includes some major changes to the setjmp/longjmp based EH mechanism to
+make it less pessimistic.  And finally, major infrastructure improvements
+to the dwarf2 EH mechanism have been made to make our EH support extensible.
+
+We have fixed the infamous security problems with temporary files. 
+
+The "regmove" optimization pass has been nearly completely rewritten.  It now
+uses much more information about the target to determine profitability of
+transformations.
+
+The compiler now recomputes register usage information immediately before
+register allocation.  Previously such information was only not kept up to
+date after instruction combination which led to poor register allocation
+choices by our priority based register allocator.
+
+The register reloading phase of the compiler has been improved to better
+optimize spill code.  This primarily helps targets which generate lots of
+spills (like the x86 ports and many register poor embedded ports).
+
+A few changes in the heuristics used by the register allocator and scheduler
+have been made which can significantly improve performance for certain
+applications.
+
+The compiler's branch shortening algorithms have been significantly improved
+to work better on targets which align jump targets.
+
+The compiler now supports the "ADDRESSOF" optimization which can significantly
+reduce the overhead for certain inline calls (and inline calls in general).
+
+The compiler now supports a code size optimization switch (-Os).  When enabled
+the compiler will prefer optimizations which improve code size over those
+which improve code speed.
+
+The compiler has been improved to completely eliminate library calls which
+compute constant values.  This is particularly useful on machines which
+do not have integer mul/div or floating point support on-chip.
+
+GCC now supports a "--help" option to print detailed help information.
+
+cpplib has been greatly improved.  It is probably useable for some sites now
+(major missing feature is trigraphs).
+
+Memory footprint for the compiler has been significantly reduced for certain
+pathalogical cases.
+
+Build time improvements for targets which support lots of sched parameters
+(alpha and mips primarily).
+
+Compile time for certain programs using large constant initializers has been
+improved (effects glibc significantly).
+
+Plus an incredible number of infrastructure changes, warning fixes, bugfixes
+and local optimizations.
+
+Various improvements have been made to better support cross compilations.  They
+are still not easy, but they are improving.
+
+Target specific NEWS
+
+    Sparc: Now includes V8 plus and V9 support, lots of tuning for Ultrasparcs
+           and uses the Haifa scheduler by default.
+
+    Alpha: EV6 tuned, optimized expansion of memcpy/bzero.
+
+    x86: Data in the static store is aligned per Intel recommendations.  Jump
+         targets are aligned per Intel recommendations.  Improved epilogue
+         sequences for Pentium chips.  Backend improvements which should help
+         register allocation on all x86 variants.  Support for PPro conditional
+         move instructions has been fixed and enabled.  Random changes
+	 throughout the port to make generated code more Pentium friendly.
+         Improved support for 64bit integer operations.
+         Unixware 7, a System V Release 5 target is now supported.
+         SCO OpenServer targets can support GAS.  See gcc/INSTALL for details.
+
+    RS6000/PowerPC: Includes AIX4.3 support as well as PowerPC64 support.  
+                    Haifa instruction scheduling is enabled by default now.
+
+    MIPS: Multiply/Multiply-Add support has been largely rewritten to generate
+          more efficient code.  Includes mips16 support.
+
+    M68K: Various micro-optimizations and Coldfire fixes.
+
+    M32r: Major improvements to this port.
+
+    Arm: Includes Thumb and super interworking support.
+
+EGCS includes all gcc2 changes up to and including the June 9, 1998 snapshot.
+
+
+Noteworthy changes in GCC version 2.8.1
+---------------------------------------
+
+Numerous bugs have been fixed and some minor performance
+improvements (compilation speed) have been made.
+
+Noteworthy changes in GCC version 2.8.0
+---------------------------------------
+
+A major change in this release is the addition of a framework for
+exception handling, currently used by C++.  Many internal changes and
+optimization improvements have been made.  These increase the
+maintainability and portability of GCC.  GCC now uses autoconf to
+compute many host parameters.
+
+The following lists changes that add new features or targets.
+
+See cp/NEWS for new features of C++ in this release.
+
+New tools and features:
+
+    The Dwarf 2 debugging information format is supported on ELF systems, and
+    is the default for -ggdb where available.  It can also be used for C++.
+    The Dwarf version 1 debugging format is also permitted for C++, but
+    does not work well.
+
+    gcov.c is provided for test coverage analysis and branch profiling
+    analysis is also supported; see -fprofile-arcs, -ftest-coverage,
+    and -fbranch-probabilities.
+
+    Support for the Checker memory checking tool.
+
+    New switch, -fstack-check, to check for stack overflow on systems that
+    don't have such built into their ABI.
+
+    New switches, -Wundef and -Wno-undef to warn if an undefined identifier
+    is evaluated in an #if directive.
+
+    Options -Wall and -Wimplicit now cause GCC to warn about implicit int
+    in declarations (e.g. `register i;'), since the C Standard committee
+    has decided to disallow this in the next revision of the standard;
+    -Wimplicit-function-declarations and -Wimplicit-int are subsets of
+    this.
+
+    Option -Wsign-compare causes GCC to warn about comparison of signed and
+    unsigned values.
+
+    Add -dI option of cccp for cxref.
+
+New features in configuration, installation and specs file handling:
+
+    New option --enable-c-cpplib to configure script.
+
+    You can use --with-cpu on the configure command to specify the default
+    CPU that GCC should generate code for.
+
+    The -specs=file switch allows you to override default specs used in
+    invoking programs like cc1, as, etc.
+
+    Allow including one specs file from another and renaming a specs
+    variable.
+
+    You can now relocate all GCC files with a single environment variable
+    or a registry entry under Windows 95 and Windows NT.
+
+Changes in Objective-C:
+
+    The Objective-C Runtime Library has been made thread-safe.
+
+    The Objective-C Runtime Library contains an interface for creating
+    mutexes, condition mutexes, and threads; it requires a back-end
+    implementation for the specific platform and/or thread package.
+    Currently supported are DEC/OSF1, IRIX, Mach, OS/2, POSIX, PCThreads,
+    Solaris, and Windows32.  The --enable-threads parameter can be used
+    when configuring GCC to enable and select a thread back-end.
+
+    Objective-C is now configured as separate front-end language to GCC,
+    making it more convenient to conditionally build it.
+
+    The internal structures of the Objective-C Runtime Library have
+    changed sufficiently to warrant a new version number; now version 8.
+    Programs compiled with an older version must be recompiled.
+
+    The Objective-C Runtime Library can be built as a DLL on Windows 95
+    and Windows NT systems.
+    
+    The Objective-C Runtime Library implements +load.
+
+The following new targets are supported (see also list under each
+individual CPU below):
+
+    Embedded target m32r-elf.
+    Embedded Hitachi Super-H using ELF.
+    RTEMS real-time system on various CPU targets.
+    ARC processor.
+    NEC V850 processor.
+    Matsushita MN10200 processor.
+    Matsushita MN10300 processor.
+    Sparc and PowerPC running on VxWorks.
+    Support both glibc versions 1 and 2 on Linux-based GNU systems.
+
+New features for DEC Alpha systems:
+
+    Allow detailed specification of IEEE fp support:
+      -mieee, -mieee-with-inexact, and -mieee-conformant
+      -mfp-trap-mode=xxx, -mfp-round-mode=xxx, -mtrap-precision=xxx
+    -mcpu=xxx for CPU selection
+    Support scheduling parameters for EV5.
+    Add support for BWX, CIX, and MAX instruction set extensions.
+    Support Linux-based GNU systems.
+    Support VMS.
+
+Additional supported processors and systems for MIPS targets:
+
+    MIPS4 instruction set.
+    R4100, R4300 and R5000 processors.
+    N32 and N64 ABI.
+    IRIX 6.2.
+    SNI SINIX.
+    
+New features for Intel x86 family:
+
+    Add scheduling parameters for Pentium and Pentium Pro.
+    Support stabs on Solaris-x86.
+    Intel x86 processors running the SCO OpenServer 5 family.
+    Intel x86 processors running DG/UX.
+    Intel x86 using Cygwin32 or Mingw32 on Windows 95 and Windows NT.
+
+New features for Motorola 68k family:
+
+    Support for 68060 processor.
+    More consistent switches to specify processor.
+    Motorola 68k family running AUX.
+    68040 running pSOS, ELF object files, DBX debugging.
+    Coldfire variant of Motorola m68k family.
+
+New features for the HP PA RISC:
+
+    -mspace and -mno-space
+    -mlong-load-store and -mno-long-load-store
+    -mbig-switch -mno-big-switch
+
+    GCC on the PA requires either gas-2.7 or the HP assembler; for best
+    results using GAS is highly recommended.  GAS is required for -g and
+    exception handling support.
+
+New features for SPARC-based systems:
+
+    The ultrasparc cpu.
+    The sparclet cpu, supporting only a.out file format.
+    Sparc running SunOS 4 with the GNU assembler.
+    Sparc running the Linux-based GNU system.
+    Embedded Sparc processors running the ELF object file format.
+    -mcpu=xxx
+    -mtune=xxx
+    -malign-loops=xxx
+    -malign-jumps=xxx
+    -malign-functions=xxx
+    -mimpure-text and -mno-impure-text
+
+    Options -mno-v8 and -mno-sparclite are no longer supported on SPARC
+    targets.  Options -mcypress, -mv8, -msupersparc, -msparclite, -mf930,
+    and -mf934 are deprecated and will be deleted in GCC 2.9.  Use
+    -mcpu=xxx instead.
+
+New features for rs6000 and PowerPC systems:
+
+    Solaris 2.51 running on PowerPC's.
+    The Linux-based GNU system running on PowerPC's.
+    -mcpu=604e,602,603e,620,801,823,mpc505,821,860,power2
+    -mtune=xxx
+    -mrelocatable-lib, -mno-relocatable-lib
+    -msim, -mmve, -memb
+    -mupdate, -mno-update
+    -mfused-madd, -mno-fused-madd
+
+    -mregnames
+    -meabi
+    -mcall-linux, -mcall-solaris, -mcall-sysv-eabi, -mcall-sysv-noeabi
+    -msdata, -msdata=none, -msdata=default, -msdata=sysv, -msdata=eabi
+    -memb, -msim, -mmvme
+    -myellowknife, -mads
+    wchar_t is now of type long as per the ABI, not unsigned short.
+    -p/-pg support
+    -mcpu=403 now implies -mstrict-align.
+    Implement System V profiling.
+
+    Aix 4.1 GCC targets now default to -mcpu=common so that programs
+    compiled can be moved between rs6000 and powerpc based systems.  A
+    consequence of this is that -static won't work, and that some programs
+    may be slightly slower.
+
+    You can select the default value to use for -mcpu=xxx on rs6000 and
+    powerpc targets by using the --with-cpu=xxx option when configuring the
+    compiler.  In addition, a new options, -mtune=xxx was added that
+    selects the machine to schedule for but does not select the
+    architecture level.
+
+    Directory names used for storing the multilib libraries on System V
+    and embedded PowerPC systems have been shortened to work with commands
+    like tar that have fixed limits on pathname size.
+
+New features for the Hitachi H8/300(H):
+
+    -malign-300
+    -ms (for the Hitachi H8/S processor)
+    -mint32
+
+New features for the ARM:
+
+    -march=xxx, -mtune=xxx, -mcpu=xxx
+    Support interworking with Thumb code.
+    ARM processor with a.out object format, COFF, or AOF assembler.
+    ARM on "semi-hosted" platform.
+    ARM running NetBSD.
+    ARM running the Linux-based GNU system.
+
+New feature for Solaris systems:
+
+    GCC installation no longer makes a copy of system include files,
+    thus insulating GCC better from updates to the operating system.
+
+
+Noteworthy changes in GCC version 2.7.2
+---------------------------------------
+
+A few bugs have been fixed (most notably the generation of an
+invalid assembler opcode on some RS/6000 systems).
+
+Noteworthy changes in GCC version 2.7.1
+---------------------------------------
+
+This release fixes numerous bugs (mostly minor) in GCC 2.7.0, but
+also contains a few new features, mostly related to specific targets.
+
+Major changes have been made in code to support Windows NT.
+
+The following new targets are supported:
+
+	2.9 BSD on PDP-11
+	Linux on m68k
+	HP/UX version 10 on HP PA RISC (treated like version 9)
+	DEC Alpha running Windows NT
+
+When parsing C, GCC now recognizes C++ style `//' comments unless you
+specify `-ansi' or `-traditional'.
+
+The PowerPC System V targets (powerpc-*-sysv, powerpc-*-eabi) now use the
+calling sequence specified in the System V Application Binary Interface
+Processor Supplement (PowerPC Processor ABI Supplement) rather than the calling
+sequence used in GCC version 2.7.0.  That calling sequence was based on the AIX
+calling sequence without function descriptors.  To compile code for that older
+calling sequence, either configure the compiler for powerpc-*-eabiaix or use
+the -mcall-aix switch when compiling and linking.
+
+Noteworthy changes in GCC version 2.7.0
+---------------------------------------
+
+GCC now works better on systems that use ".obj" and ".exe" instead of
+".o" and no extension.  This involved changes to the driver program,
+gcc.c, to convert ".o" names to ".obj" and to GCC's Makefile to use
+".obj" and ".exe" in filenames that are not targets.  In order to
+build GCC on such systems, you may need versions of GNU make and/or
+compatible shells.  At this point, this support is preliminary.
+
+Object file extensions of ".obj" and executable file extensions of
+".exe" are allowed when using appropriate version of GNU Make.
+
+Numerous enhancements were made to the __attribute__ facility including
+more attributes and more places that support it.  We now support the
+"packed", "nocommon", "noreturn", "volatile", "const", "unused",
+"transparent_union", "constructor", "destructor", "mode", "section",
+"align", "format", "weak", and "alias" attributes.  Each of these
+names may also be specified with added underscores, e.g., "__packed__".
+__attribute__ may now be applied to parameter definitions, function
+definitions, and structure, enum, and union definitions.
+
+GCC now supports returning more structures in registers, as specified by
+many calling sequences (ABIs), such as on the HP PA RISC.
+
+A new option '-fpack-struct' was added to automatically pack all structure
+members together without holes.
+
+There is a new library (cpplib) and program (cppmain) that at some
+point will replace cpp (aka cccp).  To use cppmain as cpp now, pass
+the option CCCP=cppmain to make.  The library is already used by the
+fix-header program, which should speed up the fixproto script.
+
+New options for supported targets:
+
+    GNU on many targets.
+    NetBSD on MIPS, m68k, VAX, and x86.
+    LynxOS on x86, m68k, Sparc, and RS/6000.
+    VxWorks on many targets.
+
+    Windows/NT on x86 architecture.  Initial support for Windows/NT on Alpha
+    (not fully working).
+
+    Many embedded targets, specifically UDI on a29k, aout, coff, elf,
+    and vsta "operating systems" on m68k, m88k, mips, sparc, and x86.
+
+Additional support for x86 (i386, i486, and Pentium):
+
+    Work with old and new linkers for Linux-based GNU systems,
+	supporting both a.out and ELF.
+    FreeBSD on x86.
+    Stdcall convention.
+    -malign-double, -mregparm=, -malign-loops= and -malign-jumps=  switches.
+    On ISC systems, support -Xp like -posix.
+
+Additions for RS/6000:
+
+    Instruction scheduling information for PowerPC 403.
+    AIX 4.1 on PowerPC.
+    -mstring and -mno-string.
+    -msoft-float and floating-point emulation included.
+    Preliminary support for PowerPC System V.4 with or without the GNU as.
+    Preliminary support for EABI.
+    Preliminary support for 64-bit systems.
+    Both big and little endian systems.
+
+New features for MIPS-based systems:
+
+    r4650.
+    mips4 and R8000.
+    Irix 6.0.
+    64-bit ABI.
+    Allow dollar signs in labels on SGI/Irix 5.x.
+
+New support for HP PA RISC:
+
+    Generation of PIC (requires binutils-2.5.2.u6 or later).
+    HP-UX version 9 on HP PA RISC (dynamically links even with -g).
+    Processor variants for HP PA RISC: 700, 7100, and 7100LC.
+    Automatic generation of long calls when needed.
+    -mfast-indirect-calls for kernels and static binaries.
+
+    The called routine now copies arguments passed by invisible reference,
+    as required by the calling standard.
+
+Other new miscellaneous target-specific support:
+
+    -mno-multm on a29k.
+    -mold-align for i960.
+    Configuration for "semi-hosted" ARM.
+    -momit-leaf-frame-pointer for M88k.
+    SH3 variant of Hitachi Super-H and support both big and little endian.
+
+Changes to Objective-C:
+
+    Bare-bones implementation of NXConstantString has been added,
+    which is invoked by the @"string" directive.
+
+    Class * has been changed to Class to conform to the NextSTEP and
+    OpenStep runtime.
+
+    Enhancements to make dynamic loading easier.
+
+    The module version number has been updated to Version 7, thus existing
+    code will need to be recompiled to use the current run-time library.
+
+GCC now supports the ISO Normative Addendum 1 to the C Standard.
+As a result:
+
+    The header <iso646.h> defines macros for C programs written
+    in national variants of ISO 646.
+
+    The following digraph tokens are supported:
+	<:	:>	<%	%>	%:	%:%:
+    These behave like the following, respectively:
+	[	]	{	}	#	##
+
+    Digraph tokens are supported unless you specify the `-traditional'
+    option; you do not need to specify `-ansi' or `-trigraphs'.  Except
+    for contrived and unlikely examples involving preprocessor
+    stringizing, digraph interpretation doesn't change the meaning of
+    programs; this is unlike trigraph interpretation, which changes the
+    meanings of relatively common strings.
+
+    The macro __STDC_VERSION__ has the value 199409L.
+
+  As usual, for full conformance to the standard, you also need a
+  C library that conforms.
+
+The following lists changes that have been made to g++.  If some
+features mentioned below sound unfamiliar, you will probably want to
+look at the recently-released public review copy of the C++ Working
+Paper.  For PostScript and PDF (Adobe Acrobat) versions, see the
+archive at ftp://research.att.com/dist/stdc++/WP.  For HTML and ASCII
+versions, see ftp://ftp.cygnus.com/pub/g++.  On the web, see
+http://www.cygnus.com/~mrs/wp-draft.
+
+The scope of variables declared in the for-init-statement has been changed
+to conform to http://www.cygnus.com/~mrs/wp-draft/stmt.html#stmt.for; as a
+result, packages such as groff 1.09 will not compile unless you specify the
+-fno-for-scope flag.  PLEASE DO NOT REPORT THIS AS A BUG; this is a change
+mandated by the C++ standardization committee.
+
+Binary incompatibilities:
+
+    The builtin 'bool' type is now the size of a machine word on RISC targets,
+    for code efficiency; it remains one byte long on CISC targets.
+
+    Code that does not use #pragma interface/implementation will most
+    likely shrink dramatically, as g++ now only emits the vtable for a
+    class in the translation unit where its first non-inline, non-abstract
+    virtual function is defined.
+
+    Classes that do not define the copy constructor will sometimes be
+    passed and returned in registers.  This may illuminate latent bugs in
+    your code.
+
+Support for automatic template instantiation has *NOT* been added, due
+to a disagreement over design philosophies.
+
+Support for exception handling has been improved; more targets are now
+supported, and throws will use the RTTI mechanism to match against the
+catch parameter type.  Optimization is NOT SUPPORTED with
+-fhandle-exceptions; no need to report this as a bug.
+
+Support for Run-Time Type Identification has been added with -frtti.
+This support is still in alpha; one major restriction is that any file
+compiled with -frtti must include <typeinfo.h>.
+
+Preliminary support for namespaces has been added.  This support is far
+from complete, and probably not useful.
+
+Synthesis of compiler-generated constructors, destructors and
+assignment operators is now deferred until the functions are used.
+
+The parsing of expressions such as `a ? b : c = 1' has changed from
+`(a ? b : c) = 1' to `a : b ? (c = 1)'.
+
+The code generated for testing conditions, especially those using ||
+and &&, is now more efficient.
+
+The operator keywords and, and_eq, bitand, bitor, compl, not, not_eq,
+or, or_eq, xor and xor_eq are now supported.  Use -ansi or
+-foperator-names to enable them.
+
+The 'explicit' keyword is now supported.  'explicit' is used to mark
+constructors and type conversion operators that should not be used
+implicitly.
+
+g++ now accepts the typename keyword, though it currently has no
+semantics; it can be a no-op in the current template implementation.
+You may want to start using it in your code, however, since the
+pending rewrite of the template implementation to compile STL properly
+(perhaps for 2.8.0, perhaps not) will require you to use it as
+indicated by the current draft.
+
+Handling of user-defined type conversion has been overhauled so that
+type conversion operators are now found and used properly in
+expressions and function calls.
+
+-fno-strict-prototype now only applies to function declarations with
+"C" linkage.
+
+g++ now warns about 'if (x=0)' with -Wparentheses or -Wall.
+
+#pragma weak and #pragma pack are supported on System V R4 targets, as
+are various other target-specific #pragmas supported by gcc.
+
+new and delete of const types is now allowed (with no additional
+semantics).
+
+Explicit instantiation of template methods is now supported.  Also,
+'inline template class foo<int>;' can be used to emit only the vtable
+for a template class.
+
+With -fcheck-new, g++ will check the return value of all calls to
+operator new, and not attempt to modify a returned null pointer.
+
+The template instantiation code now handles more conversions when
+passing to a parameter that does not depend on template arguments.
+This means that code like 'string s; cout << s;' now works.
+
+Invalid jumps in a switch statement past declarations that require
+initializations are now caught.
+
+Functions declared 'extern inline' now have the same linkage semantics
+as inline member functions.  On supported targets, where previously
+these functions (and vtables, and template instantiations) would have
+been defined statically, they will now be defined as weak symbols so
+that only one out-of-line definition is used.
+
+collect2 now demangles linker output, and c++filt has become part of
+the gcc distribution.
+
+Noteworthy changes in GCC version 2.6.3:
+
+A few more bugs have been fixed.
+
+Noteworthy changes in GCC version 2.6.2:
+
+A few bugs have been fixed.
+
+Names of attributes can now be preceded and followed by double underscores.
+
+Noteworthy changes in GCC version 2.6.1:
+
+Numerous (mostly minor) bugs have been fixed.
+
+The following new configurations are supported:
+
+	GNU on x86 (instead of treating it like MACH)
+	NetBSD on Sparc and Motorola 68k
+	AIX 4.1 on RS/6000 and PowerPC systems
+	Sequent DYNIX/ptx 1.x and 2.x.
+	Both COFF and ELF configurations on AViiON without using /bin/gcc
+	Windows/NT on x86 architecture; preliminary
+	AT&T DSP1610 digital signal processor chips
+	i960 systems on bare boards using COFF
+	PDP11; target only and not extensively tested
+
+The -pg option is now supported for Alpha under OSF/1 V3.0 or later.
+
+Files with an extension of ".c++" are treated as C++ code.
+
+The -Xlinker and -Wl arguments are now passed to the linker in the
+position they were specified on the command line.  This makes it
+possible, for example, to pass flags to the linker about specific
+object files.
+
+The use of positional arguments to the configure script is no longer
+recommended.  Use --target= to specify the target; see the GCC manual.
+
+The 386 now supports two new switches: -mreg-alloc=<string> changes
+the default register allocation order used by the compiler, and
+-mno-wide-multiply disables the use of the mul/imul instructions that
+produce 64 bit results in EAX:EDX from 32 bit operands to do long long
+multiplies and 32-bit division by constants.
+
+Noteworthy changes in GCC version 2.6.0:
+
+Numerous bugs have been fixed, in the C and C++ front-ends, as
+well as in the common compiler code.
+
+This release includes the C, Objective-C, and C++ compilers.  However,
+we have moved the files for the C++ compiler (G++) files to a
+subdirectory, cp.  Subsequent releases of GCC will split these files
+to a separate TAR file.
+
+The G++ team has been tracking the development of the ANSI standard for C++.
+Here are some new features added from the latest working paper:
+
+	* built-in boolean type 'bool', with constants 'true' and 'false'.
+	* array new and delete (operator new [] and delete []).
+	* WP-conforming lifetime of temporaries.
+	* explicit instantiation of templates (template class A<int>;),
+          along with an option (-fno-implicit-templates) to disable emission
+          of implicitly instantiated templates, obsoletes -fexternal-templates.
+	* static member constants (static const int foo = 4; within the
+          class declaration).
+
+Many error messages have been improved to tell the user more about the
+problem.  Conformance checking with -pedantic-errors has been
+improved.  G++ now compiles Fresco.
+
+There is now an experimental implementation of virtual functions using
+thunks instead of Cfront-style vtables, enabled with -fvtable-thunks.
+This option also enables a heuristic which causes the compiler to only
+emit the vtable in the translation unit where its first non-inline
+virtual function is defined; using this option and
+-fno-implicit-templates, users should be able to avoid #pragma
+interface/implementation altogether.
+
+Signatures have been added as a GNU C++ extension.  Using the option
+-fhandle-signatures, users are able to turn on recognition of
+signatures.  A short introduction on signatures is in the section
+`Extension to the C++ Language' in the manual.
+
+The `g++' program is now a C program, rather than a shell script.
+
+Lots and lots and lots of bugs fixes, in nested types, access control,
+pointers to member functions, the parser, templates, overload
+resolution, etc, etc.
+
+There have been two major enhancements to the Objective-C compiler:
+
+1) Added portability.  It now runs on Alpha, and some problems with
+   message forwarding have been addressed on other platforms.
+
+2) Selectors have been redefined to be pointers to structs like:
+   { void *sel_id, char *sel_types }, where the sel_id is the unique
+   identifier, the selector itself is no longer unique.  
+
+   Programmers should use the new function sel_eq to test selector
+   equivalence.
+
+The following major changes have been made to the base compiler and
+machine-specific files.
+
+- The MIL-STD-1750A is a new port, but still preliminary.
+
+- The h8/300h is now supported; both the h8/300 and h8/300h ports come
+  with 32 bit IEEE 754 software floating point support.
+
+- The 64-bit Sparc (v9) and 64-bit MIPS chips are supported.
+
+- NetBSD is supported on m68k, Intel x86, and pc523 systems and FreeBSD
+  on x86.
+
+- COFF is supported on x86, m68k, and Sparc systems running LynxOS.
+
+- 68K systems from Bull and Concurrent are supported and System V
+  Release 4 is supported on the Atari.
+
+- GCC supports GAS on the Motorola 3300 (sysV68) and debugging
+  (assuming GAS) on the Plexus 68K system.  (However, GAS does not yet
+  work on those systems).
+
+- System V Release 4 is supported on MIPS (Tandem).
+
+- For DG/UX, an ELF configuration is now supported, and both the ELF
+  and BCS configurations support ELF and COFF object file formats.
+
+- OSF/1 V2.0 is supported on Alpha.
+
+- Function profiling is also supported on Alpha.
+
+- GAS and GDB is supported for Irix 5 (MIPS).
+
+- "common mode" (code that will run on both POWER and PowerPC
+  architectures) is now supported for the RS/6000 family; the
+  compiler knows about more PPC chips.
+
+- Both NeXTStep 2.1 and 3 are supported on 68k-based architectures.
+
+- On the AMD 29k, the -msoft-float is now supported, as well as
+  -mno-sum-in-toc for RS/6000, -mapp-regs and -mflat for Sparc, and
+  -membedded-pic for MIPS.
+
+- GCC can now convert division by integer constants into the equivalent
+  multiplication and shift operations when that is faster than the
+  division.
+	
+- Two new warning options, -Wbad-function-cast and
+  -Wmissing-declarations have been added.
+
+- Configurations may now add machine-specific __attribute__ options on
+  type; many machines support the `section' attribute.
+
+- The -ffast-math flag permits some optimization that violate strict
+  IEEE rules, such as converting X * 0.0 to 0.0.
+
+Noteworthy changes in GCC version 2.5.8:
+
+This release only fixes a few serious bugs.  These include fixes for a
+bug that prevented most programs from working on the RS/6000, a bug
+that caused invalid assembler code for programs with a `switch'
+statement on the NS32K, a G++ problem that caused undefined names in
+some configurations, and several less serious problems, some of which
+can affect most configuration.
+
+Noteworthy change in GCC version 2.5.7:
+
+This release only fixes a few bugs, one of which was causing bootstrap
+compare errors on some systems.
+
+Noteworthy change in GCC version 2.5.6:
+
+A few backend bugs have been fixed, some of which only occur on one
+machine.
+
+The C++ compiler in 2.5.6 includes:
+
+ * fixes for some common crashes
+ * correct handling of nested types that are referenced as `foo::bar'
+ * spurious warnings about friends being declared static and never
+   defined should no longer appear
+ * enums that are local to a method in a class, or a class that's
+   local to a function, are now handled correctly.  For example:
+       class foo { void bar () { enum { x, y } E; x; } };
+       void bar () { class foo { enum { x, y } E; E baz; }; }
+
+Noteworthy change in GCC version 2.5.5:
+
+A large number of C++ bugs have been fixed.
+
+The fixproto script adds prototypes conditionally on __cplusplus.
+
+Noteworthy change in GCC version 2.5.4:
+
+A bug fix in passing of structure arguments for the HP-PA architecture
+makes code compiled with GCC 2.5.4 incompatible with code compiled
+with earlier versions (if it passes struct arguments of 33 to 64 bits,
+interspersed with other types of arguments).
+
+Noteworthy change in gcc version 2.5.3:
+
+The method of "mangling" C++ function names has been changed.  So you
+must recompile all C++ programs completely when you start using GCC
+2.5.  Also, GCC 2.5 requires libg++ version 2.5.  Earlier libg++
+versions won't work with GCC 2.5.  (This is generally true--GCC
+version M.N requires libg++ version M.N.)
+
+Noteworthy GCC changes in version 2.5:
+
+* There is now support for the IBM 370 architecture as a target.
+Currently the only operating system supported is MVS; GCC does not run
+on MVS, so you must produce .s files using GCC as a cross compiler,
+then transfer them to MVS to assemble them.  This port is not reliable
+yet.
+
+* The Power PC is now supported.
+
+* The i860-based Paragon machine is now supported.
+
+* The Hitachi 3050 (an HP-PA machine) is now supported.
+
+* The variable __GNUC_MINOR__ holds the minor version number of GCC, as
+an integer.  For version 2.5.X, the value is 5.
+
+* In C, initializers for static and global variables are now processed
+an element at a time, so that they don't need a lot of storage.
+
+* The C syntax for specifying which structure field comes next in an
+initializer is now `.FIELDNAME='.  The corresponding syntax for
+array initializers is now `[INDEX]='.  For example,
+
+  char whitespace[256]
+    = { [' '] = 1, ['\t'] = 1, ['\n'] = 1 };
+
+This was changed to accord with the syntax proposed by the Numerical
+C Extensions Group (NCEG).
+
+* Complex numbers are now supported in C.  Use the keyword __complex__
+to declare complex data types.  See the manual for details.
+
+* GCC now supports `long double' meaningfully on the Sparc (128-bit
+floating point) and on the 386 (96-bit floating point).  The Sparc
+support is enabled on Solaris 2.x because earlier system versions
+(SunOS 4) have bugs in the emulation.
+
+* All targets now have assertions for cpu, machine and system.  So you
+can now use assertions to distinguish among all supported targets.
+
+* Nested functions in C may now be inline.  Just declare them inline
+in the usual way.
+
+* Packed structure members are now supported fully; it should be possible 
+to access them on any supported target, no matter how little alignment
+they have.
+
+* To declare that a function does not return, you must now write
+something like this (works only in 2.5):
+
+    void fatal () __attribute__ ((noreturn));
+
+or like this (works in older versions too):
+
+    typedef void voidfn ();
+
+    volatile voidfn fatal;
+
+It used to be possible to do so by writing this:
+
+    volatile void fatal ();
+
+but it turns out that ANSI C requires that to mean something
+else (which is useless).
+
+Likewise, to declare that a function is side-effect-free
+so that calls may be deleted or combined, write
+something like this (works only in 2.5):
+
+    int computation () __attribute__ ((const));
+
+or like this (works in older versions too):
+
+    typedef int intfn ();
+
+    const intfn computation;
+
+* The new option -iwithprefixbefore specifies a directory to add to 
+the search path for include files in the same position where -I would
+put it, but uses the specified prefix just like -iwithprefix.
+
+* Basic block profiling has been enhanced to record the function the
+basic block comes from, and if the module was compiled for debugging,
+the line number and filename.  A default version of the basic block
+support module has been added to libgcc2 that appends the basic block
+information to a text file 'bb.out'.  Machine descriptions can now
+override the basic block support module in the target macro file.
+
+New features in g++:
+
+* The new flag `-fansi-overloading' for C++.  Use a newly implemented
+scheme of argument matching for C++.  It makes g++ more accurately
+obey the rules set down in Chapter 13 of the Annotated C++ Reference
+Manual (the ARM).  This option will be turned on by default in a
+future release.
+
+* The -finline-debug flag is now gone (it was never really used by the
+  compiler).
+
+* Recognizing the syntax for pointers to members, e.g., "foo::*bar", has been
+  dramatically improved.  You should not get any syntax errors or incorrect
+  runtime results while using pointers to members correctly; if you do, it's
+  a definite bug.
+
+* Forward declaration of an enum is now flagged as an error.
+
+* Class-local typedefs are now working properly.
+
+* Nested class support has been significantly improved.  The compiler
+  will now (in theory) support up to 240 nested classes before hitting
+  other system limits (like memory size).
+
+* There is a new C version of the `g++' driver, to replace the old
+  shell script.  This should significantly improve the performance of
+  executing g++ on a system where a user's PATH environment variable
+  references many NFS-mounted filesystems.  This driver also works
+  under MS-DOS and OS/2.
+
+* The ANSI committee working on the C++ standard has adopted a new
+  keyword `mutable'.  This will allow you to make a specific member be
+  modifiable in an otherwise const class.
+
+Noteworthy GCC changes in version 2.4.4:
+
+  A crash building g++ on various hosts (including m68k) has been
+  fixed.  Also the g++ compiler no longer reports incorrect
+  ambiguities in some situations where they do not exist, and
+  const template member functions are now being found properly.
+
+Noteworthy GCC changes in version 2.4:
+
+* On each target, the default is now to return short structures
+compatibly with the "usual" compiler on that target.
+
+For most targets, this means the default is to return all structures
+in memory, like long structures, in whatever way is used on that
+target.  Use -freg-struct-return to enable returning short structures
+(and unions) in registers.
+
+This change means that newly compiled binaries are incompatible with
+binaries compiled with previous versions of GCC.
+
+On some targets, GCC is itself the usual compiler.  On these targets,
+the default way to return short structures is still in registers.
+Use -fpcc-struct-return to tell GCC to return them in memory.
+
+* There is now a floating point emulator which can imitate the way all
+supported target machines do floating point arithmetic.
+
+This makes it possible to have cross compilation to and from the VAX,
+and between machines of different endianness.  However, this works
+only when the target machine description is updated to use the new
+facilities, and not all have been updated.
+
+This also makes possible support for longer floating point types.
+GCC 2.4 supports extended format on the 68K if you use `long double',
+for targets that have a 68881.  (When we have run time library
+routines for extended floating point, then `long double' will use
+extended format on all 68K targets.)
+
+We expect to support extended floating point on the i386 and Sparc in
+future versions.
+
+* Building GCC now automatically fixes the system's header files.
+This should require no attention.
+
+* GCC now installs an unsigned data type as size_t when it fixes the
+header files (on all but a handful of old target machines).
+Therefore, the bug that size_t failed to be unsigned is fixed.
+
+* Building and installation are now completely separate.
+All new files are constructed during the build process; 
+installation just copies them.
+
+* New targets supported: Clipper, Hitachi SH, Hitachi 8300, and Sparc
+Lite.
+
+* A totally new and much better Objective C run time system is included.
+
+* Objective C supports many new features.  Alas, I can't describe them
+since I don't use that language; however, they are the same ones 
+supported in recent versions of the NeXT operating system.
+
+* The builtin functions __builtin_apply_args, __builtin_apply and
+__builtin_return let you record the arguments and returned
+value of a function without knowing their number or type.
+
+* The builtin string variables __FUNCTION__ and __PRETTY_FUNCTION__
+give the name of the function in the source, and a pretty-printed
+version of the name.  The two are the same in C, but differ in C++.
+
+* Casts to union types do not yield lvalues.
+
+* ## before an empty rest argument discards the preceding sequence
+of non-whitespace characters from the macro definition.
+(This feature is subject to change.)
+
+
+New features specific to C++:
+
+* The manual contains a new section ``Common Misunderstandings with
+GNU C++'' that C++ users should read.
+
+* #pragma interface and #pragma implementation let you use the same
+C++ source file for both interface and implementation.
+However, this mechanism is still in transition.
+
+* Named returned values let you avoid an extra constructor call
+when a function result has a class type.
+
+* The C++ operators <? and >? yield min and max, respectively.
+
+* C++ gotos can exit a block safely even if the block has
+aggregates that require destructors.
+
+* gcc defines the macro __GNUG__ when compiling C++ programs.
+
+* GNU C++ now correctly distinguishes between the prefix and postfix
+forms of overloaded operator ++ and --.  To avoid breaking old
+code, if a class defines only the prefix form, the compiler
+accepts either ++obj or obj++, unless -pedantic is used.
+
+* If you are using version 2.3 of libg++, you need to rebuild it with
+`make CC=gcc' to avoid mismatches in the definition of `size_t'.
+
+Newly documented compiler options:
+
+-fnostartfiles
+	Omit the standard system startup files when linking.
+
+-fvolatile-global
+	Consider memory references to extern and global data items to
+	be volatile.
+
+-idirafter DIR
+	Add DIR to the second include path.
+
+-iprefix PREFIX
+	Specify PREFIX for later -iwithprefix options.
+
+-iwithprefix DIR
+	Add PREFIX/DIR to the second include path.
+
+-mv8
+	Emit Sparc v8 code (with integer multiply and divide).
+-msparclite
+	Emit Sparclite code (roughly v7.5).
+
+-print-libgcc-file-name
+	Search for the libgcc.a file, print its absolute file name, and exit.
+
+-Woverloaded-virtual
+	Warn when a derived class function declaration may be an error
+	in defining a C++ virtual function. 
+
+-Wtemplate-debugging
+	When using templates in a C++ program, warn if debugging is
+	not yet fully available.
+
++eN
+	Control how C++ virtual function definitions are used
+	(like cfront 1.x).
+
diff --git a/gnu/egcs/gcc/alias.c b/gnu/egcs/gcc/alias.c
index 9d8aac7832a..0cf893cf9da 100644
--- a/gnu/egcs/gcc/alias.c
+++ b/gnu/egcs/gcc/alias.c
@@ -1455,15 +1455,6 @@ init_alias_analysis ()
       new_reg_base_value[HARD_FRAME_POINTER_REGNUM]
 	= gen_rtx_ADDRESS (Pmode, hard_frame_pointer_rtx);
 #endif
-      if (struct_value_incoming_rtx
-	  && GET_CODE (struct_value_incoming_rtx) == REG)
-	new_reg_base_value[REGNO (struct_value_incoming_rtx)]
-	  = gen_rtx_ADDRESS (Pmode, struct_value_incoming_rtx);
-
-      if (static_chain_rtx
-	  && GET_CODE (static_chain_rtx) == REG)
-	new_reg_base_value[REGNO (static_chain_rtx)]
-	  = gen_rtx_ADDRESS (Pmode, static_chain_rtx);
 
       /* Walk the insns adding values to the new_reg_base_value array.  */
       for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
diff --git a/gnu/egcs/gcc/config/alpha/linux-elf.h b/gnu/egcs/gcc/config/alpha/linux-elf.h
index 50bf2307d5b..fc07127d757 100644
--- a/gnu/egcs/gcc/config/alpha/linux-elf.h
+++ b/gnu/egcs/gcc/config/alpha/linux-elf.h
@@ -38,7 +38,7 @@ Boston, MA 02111-1307, USA.  */
 
 #ifndef USE_GNULIBC_1
 #undef DEFAULT_VTABLE_THUNKS
-#define DEFAULT_VTABLE_THUNKS 2
+#define DEFAULT_VTABLE_THUNKS 1
 #endif
 
 #ifndef USE_GNULIBC_1
diff --git a/gnu/egcs/gcc/config/arm/arm.c b/gnu/egcs/gcc/config/arm/arm.c
index 553e25c7b76..70ccc3951a7 100644
--- a/gnu/egcs/gcc/config/arm/arm.c
+++ b/gnu/egcs/gcc/config/arm/arm.c
@@ -68,7 +68,7 @@ static int function_really_clobbers_lr PROTO ((rtx));
 static void emit_multi_reg_push PROTO ((int));
 static void emit_sfm PROTO ((int, int));
 static enum arm_cond_code get_arm_condition_code PROTO ((rtx));
-static int const_ok_for_op RTX_CODE_PROTO ((Hint, Rcode));
+static int const_ok_for_op RTX_CODE_PROTO ((HOST_WIDE_INT, Rcode));
 
 /* True if we are currently building a constant table. */
 int making_const_table;
@@ -490,14 +490,14 @@ arm_override_options ()
     warning ("Passing floating point arguments in fp regs not yet supported");
   
   /* Initialise boolean versions of the flags, for use in the arm.md file.  */
-  arm_fast_multiply = insn_flags & FL_FAST_MULT;
-  arm_arch4         = insn_flags & FL_ARCH4;
+  arm_fast_multiply = (insn_flags & FL_FAST_MULT) != 0;
+  arm_arch4         = (insn_flags & FL_ARCH4) != 0;
   
-  arm_ld_sched      = tune_flags & FL_LDSCHED;
-  arm_is_strong     = tune_flags & FL_STRONG;
+  arm_ld_sched      = (tune_flags & FL_LDSCHED) != 0;
+  arm_is_strong     = (tune_flags & FL_STRONG) != 0;
   arm_is_6_or_7     = ((tune_flags & (FL_MODE26 | FL_MODE32))
 		       && !(tune_flags & FL_ARCH4));
-  
+
   /* Default value for floating point code... if no co-processor
      bus, then schedule for emulated floating point.  Otherwise,
      assume the user has an FPA.
diff --git a/gnu/egcs/gcc/config/arm/arm.h b/gnu/egcs/gcc/config/arm/arm.h
index 3c133a01b0e..8bc200a1ceb 100644
--- a/gnu/egcs/gcc/config/arm/arm.h
+++ b/gnu/egcs/gcc/config/arm/arm.h
@@ -2148,7 +2148,6 @@ struct rtx_def;
 #ifndef HOST_WIDE_INT
 #include "hwint.h"
 #endif
-#define Hint HOST_WIDE_INT
 
 #ifndef HAVE_MACHINE_MODES
 #include "machmode.h"
@@ -2164,8 +2163,8 @@ struct rtx_def;
 
 void   arm_override_options PROTO ((void));
 int    use_return_insn PROTO ((int));
-int    const_ok_for_arm PROTO ((Hint));
-int    arm_split_constant RTX_CODE_PROTO ((Rcode, Mmode, Hint, Rtx, Rtx, int));
+int    const_ok_for_arm PROTO ((HOST_WIDE_INT));
+int    arm_split_constant RTX_CODE_PROTO ((Rcode, Mmode, HOST_WIDE_INT, Rtx, Rtx, int));
 Rcode  arm_canonicalize_comparison RTX_CODE_PROTO ((Rcode,  Rtx *));
 int    arm_return_in_memory PROTO ((Tree));
 int    legitimate_pic_operand_p PROTO ((Rtx));
@@ -2206,9 +2205,9 @@ Rcode  minmax_code PROTO ((Rtx));
 int    adjacent_mem_locations PROTO ((Rtx, Rtx));
 int    load_multiple_operation PROTO ((Rtx, Mmode));
 int    store_multiple_operation PROTO ((Rtx, Mmode));
-int    load_multiple_sequence PROTO ((Rtx *, int, int *, int *, Hint *));
+int    load_multiple_sequence PROTO ((Rtx *, int, int *, int *, HOST_WIDE_INT *));
 char * emit_ldm_seq PROTO ((Rtx *, int));
-int    store_multiple_sequence PROTO ((Rtx *, int, int *, int *, Hint *));
+int    store_multiple_sequence PROTO ((Rtx *, int, int *, int *, HOST_WIDE_INT *));
 char * emit_stm_seq PROTO ((Rtx *, int));
 int    arm_valid_machine_decl_attribute PROTO ((Tree, Tree, Tree));
 Rtx    arm_gen_load_multiple PROTO ((int, int, Rtx, int, int, int, int, int));
diff --git a/gnu/egcs/gcc/config/arm/arm.md b/gnu/egcs/gcc/config/arm/arm.md
index 7ccbb5cb2d1..d5047f82dae 100644
--- a/gnu/egcs/gcc/config/arm/arm.md
+++ b/gnu/egcs/gcc/config/arm/arm.md
@@ -5798,15 +5798,19 @@
 ; It doesn't seem worth adding peepholes for anything but the most common
 ; cases since, unlike combine, the increment must immediately follow the load
 ; for this pattern to match.
-; When loading we must watch to see that the base register isn't trampled by
-; the load.  In such cases this isn't a post-inc expression.
+; We must watch to see that the source/destination register isn't also the
+; same as the base address register, and that if the index is a register,
+; that it is not the same as the base address register.  In such cases the
+; instruction that we would generate would have UNPREDICTABLE behaviour so 
+; we cannot use it.
 
 (define_peephole
   [(set (mem:QI (match_operand:SI 0 "s_register_operand" "+r"))
 	(match_operand:QI 2 "s_register_operand" "r"))
    (set (match_dup 0)
 	(plus:SI (match_dup 0) (match_operand:SI 1 "index_operand" "rJ")))]
-  ""
+  "(REGNO (operands[2]) != REGNO (operands[0]))
+   && (GET_CODE (operands[1]) != REG || (REGNO (operands[1]) != REGNO (operands[0])))"
   "str%?b\\t%2, [%0], %1")
 
 (define_peephole
@@ -5814,9 +5818,8 @@
 	(mem:QI (match_operand:SI 1 "s_register_operand" "+r")))
    (set (match_dup 1)
 	(plus:SI (match_dup 1) (match_operand:SI 2 "index_operand" "rJ")))]
-  "REGNO(operands[0]) != REGNO(operands[1])
-   && (GET_CODE (operands[2]) != REG
-       || REGNO(operands[0]) != REGNO (operands[2]))"
+  "REGNO (operands[0]) != REGNO (operands[1])
+   && (GET_CODE (operands[2]) != REG || REGNO (operands[0]) != REGNO (operands[2]))"
   "ldr%?b\\t%0, [%1], %2")
 
 (define_peephole
@@ -5824,7 +5827,8 @@
 	(match_operand:SI 2 "s_register_operand" "r"))
    (set (match_dup 0)
 	(plus:SI (match_dup 0) (match_operand:SI 1 "index_operand" "rJ")))]
-  ""
+  "(REGNO (operands[2]) != REGNO (operands[0]))
+   && (GET_CODE (operands[1]) != REG || (REGNO (operands[1]) != REGNO (operands[0])))"
   "str%?\\t%2, [%0], %1")
 
 (define_peephole
@@ -5834,9 +5838,8 @@
 	(plus:SI (match_dup 1) (match_operand:SI 2 "index_operand" "rJ")))]
   "(! BYTES_BIG_ENDIAN)
    && ! TARGET_SHORT_BY_BYTES
-   && REGNO(operands[0]) != REGNO(operands[1])
-   && (GET_CODE (operands[2]) != REG
-       || REGNO(operands[0]) != REGNO (operands[2]))"
+   && REGNO (operands[0]) != REGNO (operands[1])
+   && (GET_CODE (operands[2]) != REG || REGNO (operands[0]) != REGNO (operands[2]))"
   "ldr%?\\t%0, [%1], %2\\t%@ loadhi")
 
 (define_peephole
@@ -5844,9 +5847,8 @@
 	(mem:SI (match_operand:SI 1 "s_register_operand" "+r")))
    (set (match_dup 1)
 	(plus:SI (match_dup 1) (match_operand:SI 2 "index_operand" "rJ")))]
-  "REGNO(operands[0]) != REGNO(operands[1])
-   && (GET_CODE (operands[2]) != REG
-       || REGNO(operands[0]) != REGNO (operands[2]))"
+  "REGNO (operands[0]) != REGNO (operands[1])
+   && (GET_CODE (operands[2]) != REG || REGNO (operands[0]) != REGNO (operands[2]))"
   "ldr%?\\t%0, [%1], %2")
 
 (define_peephole
@@ -5854,7 +5856,8 @@
 			 (match_operand:SI 1 "index_operand" "rJ")))
 	(match_operand:QI 2 "s_register_operand" "r"))
    (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 1)))]
-  ""
+  "(REGNO (operands[2]) != REGNO (operands[0]))
+   && (GET_CODE (operands[1]) != REG || (REGNO (operands[1]) != REGNO (operands[0])))"
   "str%?b\\t%2, [%0, %1]!")
 
 (define_peephole
@@ -5865,7 +5868,8 @@
 	(match_operand:QI 3 "s_register_operand" "r"))
    (set (match_dup 2) (plus:SI (match_op_dup 4 [(match_dup 0) (match_dup 1)])
 			       (match_dup 2)))]
-  ""
+  "REGNO (operands[0]) != REGNO (operands[2])
+   && REGNO (operands[3]) != REGNO (operands[2])"
   "str%?b\\t%3, [%2, %0%S4]!")
 
 ; This pattern is never tried by combine, so do it as a peephole
diff --git a/gnu/egcs/gcc/config/arm/linux-elf.h b/gnu/egcs/gcc/config/arm/linux-elf.h
index 956ecba5348..41bafef3326 100644
--- a/gnu/egcs/gcc/config/arm/linux-elf.h
+++ b/gnu/egcs/gcc/config/arm/linux-elf.h
@@ -28,18 +28,35 @@ Boston, MA 02111-1307, USA.  */
 /* We have libgcc2.  */
 #define HAVE_ATEXIT
 
-/* Default is to use APCS-32 mode.  */
 #ifndef SUBTARGET_DEFAULT_APCS26
-#define TARGET_DEFAULT (ARM_FLAG_APCS_32 | ARM_FLAG_SHORT_BYTE)
-#define SUBTARGET_EXTRA_LINK_SPEC	\
+/* Default is to use APCS-32 mode.  */
+# define TARGET_DEFAULT (ARM_FLAG_APCS_32 | ARM_FLAG_SHORT_BYTE)
+# ifdef SUBTARGET_OLD_LINKER
+#  define SUBTARGET_EXTRA_LINK_SPEC	\
 	" %{mapcs-26:-m elf32arm26} %{!mapcs-26:-m elf32arm}"
-#define SUBTARGET_EXTRA_ASM_SPEC	\
+# else	/* new linker */
+#  define SUBTARGET_EXTRA_LINK_SPEC	\
+	" %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p"
+# endif
+# define SUBTARGET_EXTRA_ASM_SPEC	\
 	" %{mapcs-26:-mapcs-26} %(!mapcs-26:-mapcs-32}"
+# define CPP_APCS_PC_DEFAULT_SPEC "-D__APCS_32__"
+#else	/* default is APCS-26 */
+# define TARGET_DEFAULT (ARM_FLAG_SHORT_BYTE)
+# ifdef SUBTARGET_OLD_LINKER
+#  define SUBTARGET_LINK_SPEC	\
+	" %{mapcs-32:-m elf32arm} %{!mapcs-32:-m elf32arm26}"
+# else	/* new linker */
+#  define SUBTARGET_LINK_SPEC	\
+	" %{mapcs-32:-m armelf_linux} %{!mapcs-32:-m armelf_linux26} -p"
+# endif
+# define SUBTARGET_EXTRA_ASM_SPEC	\
+	" %{mapcs-32:-mapcs-32} %(!mapcs-32:-mapcs-26}"
 #endif
 
 /* This was defined in linux.h.  Define it here also. */
 #undef  DEFAULT_VTABLE_THUNKS
-#define DEFAULT_VTABLE_THUNKS   2
+#define DEFAULT_VTABLE_THUNKS   1
 
 /* Handle #pragma weak and #pragma pack.  */
 #define HANDLE_SYSV_PRAGMA
@@ -86,8 +103,8 @@ Boston, MA 02111-1307, USA.  */
 
 #undef  CPP_PREDEFINES
 #define CPP_PREDEFINES \
-"-Dunix -Darm -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(arm) \
--Amachine(arm) -D__ELF__ -Darm_elf"
+"-Dunix -D__arm__ -Dlinux -Asystem(unix) -Asystem(posix) -Acpu(arm) \
+-Amachine(arm) -D__ELF__"
 
 #ifndef SUBTARGET_DEFAULT_APCS26
 #define CPP_APCS_PC_DEFAULT_SPEC "-D__APCS_32__"
diff --git a/gnu/egcs/gcc/config/arm/linux-elf26.h b/gnu/egcs/gcc/config/arm/linux-elf26.h
index aa65ae7f750..ce26f1fef9d 100644
--- a/gnu/egcs/gcc/config/arm/linux-elf26.h
+++ b/gnu/egcs/gcc/config/arm/linux-elf26.h
@@ -1,6 +1,7 @@
-/* Definitions for 26-bit ARM running Linux-based GNU systems using ELF
-   Copyright (C) 1998 Free Software Foundation, Inc.
-   Contributed by Philip Blundell <philb@gnu.org>
+/* Definitions for ARM running Linux-based GNU systems 
+   using ELF and 26-bit APCS.
+   Copyright (C) 1999 Free Software Foundation, Inc.
+   Contributed by Philip Blundell <Philip.Blundell@pobox.com>
 
 This file is part of GNU CC.
 
@@ -19,14 +20,5 @@ along with this program; see the file COPYING.  If not, write to
 the Free Software Foundation, 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.  */
 
+/* Tell linux-elf.h to default to 26-bit mode.  */
 #define SUBTARGET_DEFAULT_APCS26
-
-#define SUBTARGET_LINK_SPEC	\
-	" %{mapcs-32:-m elf32arm} %{!mapcs-32:-m elf32arm26}"
-
-#define SUBTARGET_EXTRA_ASM_SPEC	\
-	" %{mapcs-32:-mapcs-32} %(!mapcs-32:-mapcs-26}"
-
-#define TARGET_DEFAULT (ARM_FLAG_SHORT_BYTE)
-
-#include "arm/linux-elf.h"
diff --git a/gnu/egcs/gcc/config/arm/linux-oldld.h b/gnu/egcs/gcc/config/arm/linux-oldld.h
new file mode 100644
index 00000000000..8b2af015efe
--- /dev/null
+++ b/gnu/egcs/gcc/config/arm/linux-oldld.h
@@ -0,0 +1,27 @@
+/* Definitions for ARM running Linux-based GNU systems 
+   using ELF with old binutils.
+   Copyright (C) 1999 Free Software Foundation, Inc.
+   Contributed by Philip Blundell <Philip.Blundell@pobox.com>
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* Unfortunately, owing to various historical accidents, version 2.9.4
+   and newer of GNU binutils are not quite compatible with the old 
+   (2.9.1-based) toolset.  This tells linux-elf.h to generate specs
+   appropriate for the older versions.  */
+#define SUBTARGET_OLD_LINKER
diff --git a/gnu/egcs/gcc/config/h8300/h8300.c b/gnu/egcs/gcc/config/h8300/h8300.c
index 5fb4a628c46..b48a68bbc54 100644
--- a/gnu/egcs/gcc/config/h8300/h8300.c
+++ b/gnu/egcs/gcc/config/h8300/h8300.c
@@ -396,7 +396,7 @@ function_epilogue (file, size)
   if (GET_CODE (insn) == NOTE)
     insn = prev_nonnote_insn (insn);
   if (insn && GET_CODE (insn) == BARRIER)
-    return;
+    goto out;
 
   /* Pop the saved registers. */
   for (idx = 0; idx < FIRST_PSEUDO_REGISTER; idx++)
@@ -2313,9 +2313,9 @@ get_shift_alg (cpu, shift_type, mode, count, assembler_p,
 	      if (TARGET_H8300)
 		*assembler_p = "mov.b\t%t0,%s0\n\tbld\t#7,%s0\n\tsubx\t%t0,%t0\n\tshar.b\t%s0\n\tshar.b\t%s0\n\tshar.b\t%s0\n\tshar.b\t%s0";
 	      else if (TARGET_H8300H)
-		*assembler_p = "mov.b\t%t0,%s0\n\textw.w\t%T0\n\tshar.b\t%s0\n\tshar.b\t%s0\n\tshar.b\t%s0\n\tshar.b\t%s0";
+		*assembler_p = "mov.b\t%t0,%s0\n\texts.w\t%T0\n\tshar.b\t%s0\n\tshar.b\t%s0\n\tshar.b\t%s0\n\tshar.b\t%s0";
 	      else if (TARGET_H8300S)
-		*assembler_p = "mov.b\t%t0,%s0\n\textw.w\t%T0\n\tshar.b\t#2,%s0\n\tshar.b\t#2,%s0";
+		*assembler_p = "mov.b\t%t0,%s0\n\texts.w\t%T0\n\tshar.b\t#2,%s0\n\tshar.b\t#2,%s0";
 	      *cc_valid_p = 0;
 	      return SHIFT_SPECIAL;
 	    }
diff --git a/gnu/egcs/gcc/config/h8300/h8300.md b/gnu/egcs/gcc/config/h8300/h8300.md
index da6519300e9..016a524d29e 100644
--- a/gnu/egcs/gcc/config/h8300/h8300.md
+++ b/gnu/egcs/gcc/config/h8300/h8300.md
@@ -414,7 +414,7 @@
   if (which_alternative == 7)
     return \"clrmac\;ldmac %1,macl\";
   if (which_alternative == 8)
-    return \"stmac macl,%0\";
+    return \"stmac	macl,%0\";
   if (GET_CODE (operands[1]) == CONST_INT)
     {
       int val = INTVAL (operands[1]);
@@ -861,7 +861,7 @@
 	  (sign_extend:SI
 	    (mem:HI (post_inc:SI (match_operand:SI 2 "register_operand" "r"))))))]
   "TARGET_H8300S"
-  "clrmac\;mac	%2,%1"
+  "clrmac\;mac	@%2+,@%1+"
   [(set_attr "length" "6")
    (set_attr "cc" "none_0hit")])
 
@@ -874,7 +874,7 @@
 	    (post_inc:SI (match_operand:SI 2 "register_operand" "r")))))
 	      (match_operand:SI 3 "register_operand" "0")))]
   "TARGET_H8300S"
-  "mac	%2,%1"
+  "mac	@%2+,@%1+"
   [(set_attr "length" "4")
    (set_attr "cc" "none_0hit")])
 
@@ -1674,7 +1674,7 @@
 
 (define_expand "zero_extendhisi2"
   [(set (match_operand:SI 0 "register_operand" "")
-	(zero_extend:SI (match_operand:HI 1 "general_operand" "")))]
+	(zero_extend:SI (match_operand:HI 1 "register_operand" "")))]
   ""
   "
 {
@@ -1709,18 +1709,16 @@
    (set_attr "cc" "clobber,clobber,clobber")])
 
 (define_insn ""
-  [(set (match_operand:SI 0 "register_operand" "=r,r")
-	(zero_extend:SI (match_operand:HI 1 "general_operand_src" "0,g>")))]
+  [(set (match_operand:SI 0 "register_operand" "=r")
+	(zero_extend:SI (match_operand:HI 1 "register_operand" "0")))]
   "TARGET_H8300H || TARGET_H8300S"
-  "@
-  extu.l	%S0
-  mov.w	%T1,%T0\;extu.l	%S0"
-  [(set_attr "length" "2,4")
-   (set_attr "cc" "set_znv,set_znv")])
+  "extu.l	%S0"
+  [(set_attr "length" "2")
+   (set_attr "cc" "set_znv")])
 
 (define_expand "extendqihi2"
   [(set (match_operand:HI 0 "register_operand" "")
-	(sign_extend:HI (match_operand:QI 1 "general_operand" "")))]
+	(sign_extend:HI (match_operand:QI 1 "register_operand" "")))]
   ""
   "")
 
@@ -1735,14 +1733,12 @@
    (set_attr "cc" "clobber,clobber")])
 
 (define_insn ""
-  [(set (match_operand:HI 0 "register_operand" "=r,r")
-	(sign_extend:HI (match_operand:QI 1 "general_operand_src" "0,g>")))]
+  [(set (match_operand:HI 0 "register_operand" "=r")
+	(sign_extend:HI (match_operand:QI 1 "register_operand" "0")))]
   "TARGET_H8300H || TARGET_H8300S"
-  "@
-  exts.w	%T0
-  mov.b	%R1,%s0\;exts.w	%T0"
-  [(set_attr "length" "2,4")
-   (set_attr "cc" "set_znv,set_znv")])
+  "exts.w	%T0"
+  [(set_attr "length" "2")
+   (set_attr "cc" "set_znv")])
 
 ;; The compiler can synthesize a 300H variant of this which is
 ;; just as efficient as one that we'd create
@@ -1758,7 +1754,7 @@
 
 (define_expand "extendhisi2"
   [(set (match_operand:SI 0 "register_operand" "")
-	(sign_extend:SI (match_operand:HI 1 "general_operand" "")))]
+	(sign_extend:SI (match_operand:HI 1 "register_operand" "")))]
   ""
   "
 {
@@ -1791,14 +1787,12 @@
    (set_attr "cc" "clobber,clobber")])
 
 (define_insn ""
-  [(set (match_operand:SI 0 "register_operand" "=r,r")
-	(sign_extend:SI (match_operand:HI 1 "general_operand_src" "0,g>")))]
+  [(set (match_operand:SI 0 "register_operand" "=r")
+	(sign_extend:SI (match_operand:HI 1 "register_operand" "0")))]
   "TARGET_H8300H || TARGET_H8300S"
-  "@
-  exts.l	%S0
-  mov.w	%T1,%T0\;exts.l	%S0"
-  [(set_attr "length" "2,4")
-   (set_attr "cc" "set_znv,set_znv")])
+  "exts.l	%S0"
+  [(set_attr "length" "2")
+   (set_attr "cc" "set_znv")])
 
 ;; ----------------------------------------------------------------------
 ;; SHIFTS
diff --git a/gnu/egcs/gcc/config/i386/dgux.h b/gnu/egcs/gcc/config/i386/dgux.h
index 2776d783d88..4e0b7c7cd4f 100644
--- a/gnu/egcs/gcc/config/i386/dgux.h
+++ b/gnu/egcs/gcc/config/i386/dgux.h
@@ -26,7 +26,7 @@ Boston, MA 02111-1307, USA.  */
 #include "i386/sysv4.h"
 
 #ifndef VERSION_INFO2
-#define VERSION_INFO2   "$Revision: 1.1.1.2 $"
+#define VERSION_INFO2   "$Revision: 1.1.1.3 $"
 #endif
 
 #ifndef VERSION_STRING
diff --git a/gnu/egcs/gcc/config/i386/freebsd-elf.h b/gnu/egcs/gcc/config/i386/freebsd-elf.h
index 8c907bf9d1e..e97d4ca07bb 100644
--- a/gnu/egcs/gcc/config/i386/freebsd-elf.h
+++ b/gnu/egcs/gcc/config/i386/freebsd-elf.h
@@ -37,7 +37,7 @@ Boston, MA 02111-1307, USA.  */
 
 /* Use more efficient ``thunks'' to implement C++ vtables. */
 #undef DEFAULT_VTABLE_THUNKS
-#define DEFAULT_VTABLE_THUNKS 2
+#define DEFAULT_VTABLE_THUNKS 1
 
 /* Override the default comment-starter of "/".  */
 #undef ASM_COMMENT_START
diff --git a/gnu/egcs/gcc/config/i386/xm-uwin.h b/gnu/egcs/gcc/config/i386/xm-uwin.h
index 2e1ecde0fa7..e69de29bb2d 100644
--- a/gnu/egcs/gcc/config/i386/xm-uwin.h
+++ b/gnu/egcs/gcc/config/i386/xm-uwin.h
@@ -1,39 +0,0 @@
-/* Configuration for GNU C-compiler for hosting on Windows32.
-   using GNU tools and the Windows32 API Library.
-   Copyright (C) 1999 Free Software Foundation, Inc.
-   Contributed by Mumit Khan  <khan@xraylith.wisc.edu>.
-
-This file is part of GNU CC.
-
-GNU CC is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2, or (at your option)
-any later version.
-
-GNU CC is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GNU CC; see the file COPYING.  If not, write to
-the Free Software Foundation, 59 Temple Place - Suite 330,
-Boston, MA 02111-1307, USA. */
-
-#ifndef ONLY_INT_FIELD
-#define ONLY_INT_FIELDS 1
-#endif
-
-#ifndef USE_PROTOTYPES
-#define USE_PROTOTYPES 1
-#endif
-
-/* U/WIN system calls only support '/' */
-#undef DIR_SEPARATOR
-#define DIR_SEPARATOR '/'
-#undef EXECUTABLE_SUFFIX
-#define EXECUTABLE_SUFFIX ".exe"
-
-#undef PATH_SEPARATOR
-#define PATH_SEPARATOR ':'
-
diff --git a/gnu/egcs/gcc/config/linux.h b/gnu/egcs/gcc/config/linux.h
index 46ce8988223..b619d01cdf5 100644
--- a/gnu/egcs/gcc/config/linux.h
+++ b/gnu/egcs/gcc/config/linux.h
@@ -89,7 +89,7 @@ Boston, MA 02111-1307, USA.  */
 
 #ifndef USE_GNULIBC_1
 #undef DEFAULT_VTABLE_THUNKS
-#define DEFAULT_VTABLE_THUNKS 2
+#define DEFAULT_VTABLE_THUNKS 1
 #endif
 
 #undef	LIB_SPEC
diff --git a/gnu/egcs/gcc/config/m68k/mot3300-crt0.S b/gnu/egcs/gcc/config/m68k/mot3300-crt0.S
index 65678cf698b..324115b534a 100644
--- a/gnu/egcs/gcc/config/m68k/mot3300-crt0.S
+++ b/gnu/egcs/gcc/config/m68k/mot3300-crt0.S
@@ -93,6 +93,6 @@ __stop_monitor:
 	COMM	splimit%,4
 	COMM	environ,4
 
-	IDENT ("$Id: mot3300-crt0.S,v 1.1.1.4 2000/09/24 23:22:42 espie Exp $")
+	IDENT ("$Id: mot3300-crt0.S,v 1.1.1.5 2001/01/29 15:15:45 espie Exp $")
 	IDENT ("Contributed by Manfred Hollstein (manfred@lts.sel.alcatel.de)")
 	IDENT ("Corrections by Philippe De Muyter (phdm@macqel.be)")
diff --git a/gnu/egcs/gcc/config/m68k/mot3300Mcrt0.S b/gnu/egcs/gcc/config/m68k/mot3300Mcrt0.S
index c581d280b29..b3e52bd2335 100644
--- a/gnu/egcs/gcc/config/m68k/mot3300Mcrt0.S
+++ b/gnu/egcs/gcc/config/m68k/mot3300Mcrt0.S
@@ -137,6 +137,6 @@ LOCAL_LABEL(endofstart):
 	COMM	environ,4
 	COMM	_countbase,4
 
-	IDENT ("$Id: mot3300Mcrt0.S,v 1.1.1.4 2000/09/24 23:22:42 espie Exp $")
+	IDENT ("$Id: mot3300Mcrt0.S,v 1.1.1.5 2001/01/29 15:15:46 espie Exp $")
 	IDENT ("Contributed by Manfred Hollstein (manfred@lts.sel.alcatel.de)")
 	IDENT ("Corrections by Philippe De Muyter (phdm@macqel.be)")
diff --git a/gnu/egcs/gcc/config/m88k/dgux.h b/gnu/egcs/gcc/config/m88k/dgux.h
index ee7bd6829cc..33234c8182c 100644
--- a/gnu/egcs/gcc/config/m88k/dgux.h
+++ b/gnu/egcs/gcc/config/m88k/dgux.h
@@ -30,7 +30,7 @@ Boston, MA 02111-1307, USA.  */
   (TARGET_SVR4 ? DWARF_DEBUG : SDB_DEBUG)
 
 #ifndef VERSION_INFO2
-#define VERSION_INFO2   "$Revision: 1.1.1.4 $"
+#define VERSION_INFO2   "$Revision: 1.1.1.5 $"
 #endif
 #ifndef NO_BUGS
 #define AS_BUG_IMMEDIATE_LABEL
diff --git a/gnu/egcs/gcc/config/mips/vxworks.h b/gnu/egcs/gcc/config/mips/vxworks.h
index 0856c37343a..25d9ef90cc8 100644
--- a/gnu/egcs/gcc/config/mips/vxworks.h
+++ b/gnu/egcs/gcc/config/mips/vxworks.h
@@ -1,4 +1,4 @@
-/* Copyright (C) 1999 Free Software Foundation, Inc. */
+/* Copyright (C) 1999 Free Software Foundation, Inc.
 
 This file is part of GNU CC.
 
diff --git a/gnu/egcs/gcc/config/rs6000/linux.h b/gnu/egcs/gcc/config/rs6000/linux.h
index 8210076245a..c2a04fa85b1 100644
--- a/gnu/egcs/gcc/config/rs6000/linux.h
+++ b/gnu/egcs/gcc/config/rs6000/linux.h
@@ -69,7 +69,7 @@ Boston, MA 02111-1307, USA.  */
 
 #undef DEFAULT_VTABLE_THUNKS
 #ifndef USE_GNULIBC_1
-#define DEFAULT_VTABLE_THUNKS 2
+#define DEFAULT_VTABLE_THUNKS 1
 #endif
 
 #undef JUMP_TABLES_IN_TEXT_SECTION
diff --git a/gnu/egcs/gcc/config/rs6000/rs6000.md b/gnu/egcs/gcc/config/rs6000/rs6000.md
index 0211728fa19..c8078e0712d 100644
--- a/gnu/egcs/gcc/config/rs6000/rs6000.md
+++ b/gnu/egcs/gcc/config/rs6000/rs6000.md
@@ -27,12 +27,14 @@
   (const_string "integer"))
 
 ;; Length (in bytes).
+; '(pc)' in the following doesn't include the instruction itself; it is 
+; calculated as if the instruction had zero size.
 (define_attr "length" ""
   (if_then_else (eq_attr "type" "branch")
-		(if_then_else (and (ge (minus (pc) (match_dup 0))
+		(if_then_else (and (ge (minus (match_dup 0) (pc))
 				       (const_int -32768))
-				   (lt (minus (pc) (match_dup 0))
-				       (const_int 32767)))
+				   (lt (minus (match_dup 0) (pc))
+				       (const_int 32764)))
 			      (const_int 8)
 			      (const_int 12))
 		(const_int 4)))
@@ -5463,31 +5465,31 @@
 (define_insn "*anddi3_internal2"
   [(set (match_operand:CC 0 "cc_reg_operand" "=x,x,x,x")
 	(compare:CC (and:DI (match_operand:DI 1 "gpc_reg_operand" "%r,r,r,r")
-			    (match_operand:DI 2 "and64_operand" "r,K,J,S"))
+			    (match_operand:DI 2 "and64_operand" "r,S,K,J"))
 		    (const_int 0)))
    (clobber (match_scratch:DI 3 "=r,r,r,r"))]
   "TARGET_POWERPC64"
   "@
    and. %3,%1,%2
+   rldic%B2. %3,%1,0,%S2
    andi. %3,%1,%b2
-   andis. %3,%1,%u2
-   rldic%B2. %3,%1,0,%S2"
-  [(set_attr "type" "compare,compare,compare,delayed_compare")])
+   andis. %3,%1,%u2"
+  [(set_attr "type" "compare,delayed_compare,compare,compare")])
 
 (define_insn "*anddi3_internal3"
   [(set (match_operand:CC 3 "cc_reg_operand" "=x,x,x,x")
 	(compare:CC (and:DI (match_operand:DI 1 "gpc_reg_operand" "%r,r,r,r")
-			    (match_operand:DI 2 "and64_operand" "r,K,J,S"))
+			    (match_operand:DI 2 "and64_operand" "r,S,K,J"))
 		    (const_int 0)))
    (set (match_operand:DI 0 "gpc_reg_operand" "=r,r,r,r")
 	(and:DI (match_dup 1) (match_dup 2)))]
   "TARGET_POWERPC64"
   "@
    and. %0,%1,%2
+   rldic%B2. %0,%1,0,%S2
    andi. %0,%1,%b2
-   andis. %0,%1,%u2
-   rldic%B2. %0,%1,0,%S2"
-  [(set_attr "type" "compare,compare,compare,delayed_compare")])
+   andis. %0,%1,%u2"
+  [(set_attr "type" "compare,delayed_compare,compare,compare")])
 
 (define_expand "iordi3"
   [(set (match_operand:DI 0 "gpc_reg_operand" "")
@@ -6774,9 +6776,12 @@
   [(set (match_dup 0)
 	(match_dup 2))
    (set (match_dup 0)
-	(zero_extend:DI (subreg:SI (match_dup 0) 0)))]
+	(zero_extend:DI (match_dup 3)))]
   "
-{ operands[2] = GEN_INT (CONST_DOUBLE_LOW (operands[1])); }")
+{ 
+  operands[2] = GEN_INT (CONST_DOUBLE_LOW (operands[1])); 
+  operands[3] = gen_lowpart_common (SImode, operands[0]);
+}")
 
 (define_split
   [(set (match_operand:DI 0 "gpc_reg_operand" "")
diff --git a/gnu/egcs/gcc/config/sparc/linux.h b/gnu/egcs/gcc/config/sparc/linux.h
index 40694908b68..d967b01ebe3 100644
--- a/gnu/egcs/gcc/config/sparc/linux.h
+++ b/gnu/egcs/gcc/config/sparc/linux.h
@@ -37,7 +37,7 @@ Boston, MA 02111-1307, USA.  */
 
 #ifndef USE_GNULIBC_1
 #undef DEFAULT_VTABLE_THUNKS
-#define DEFAULT_VTABLE_THUNKS 2
+#define DEFAULT_VTABLE_THUNKS 1
 #endif
 
 /* Use stabs instead of DWARF debug format.  */
diff --git a/gnu/egcs/gcc/cp/lang-specs.h b/gnu/egcs/gcc/cp/lang-specs.h
index 648bc1f0953..baa2fcd8f4b 100644
--- a/gnu/egcs/gcc/cp/lang-specs.h
+++ b/gnu/egcs/gcc/cp/lang-specs.h
@@ -30,7 +30,7 @@ Boston, MA 02111-1307, USA.  */
   {"@c++",
 #if USE_CPPLIB
    {
-     "%{E|M|MM:cpp -lang-c++ %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
+     "%{E|M|MM:cpp0 -lang-c++ %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
 	%{C:%{!E:%eGNU C++ does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
 	%{!no-gcc:-D__GNUC__=%v1 -D__GNUG__=%v1 -D__GNUC_MINOR__=%v2}\
@@ -62,7 +62,7 @@ Boston, MA 02111-1307, USA.  */
 		      %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\
                       %{!pipe:%g.s} %A\n }}}}"}},
 #else /* ! USE_CPPLIB */
-   {"cpp -lang-c++ %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
+   {"cpp0 -lang-c++ %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
 	%{C:%{!E:%eGNU C++ does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
 	%{!no-gcc:-D__GNUC__=%v1 -D__GNUG__=%v1 -D__GNUC_MINOR__=%v2}\
diff --git a/gnu/egcs/gcc/dwarf2.h b/gnu/egcs/gcc/dwarf2.h
index ddbe1b823bb..d0ca2451b76 100644
--- a/gnu/egcs/gcc/dwarf2.h
+++ b/gnu/egcs/gcc/dwarf2.h
@@ -1,6 +1,7 @@
 /* Declarations and definitions of codes relating to the DWARF2 symbolic
    debugging information format.
-   Copyright (C) 1992, 1993, 1995, 1996, 1997 Free Software Foundation, Inc.
+   Copyright (C) 1992, 1993, 1995, 1996, 1997, 2000 
+   Free Software Foundation, Inc.
    Contributed by Gary Funck (gary@intrepid.com).  Derived from the
    DWARF 1 implementation written by Ron Guilmette (rfg@monkeys.com).
 
@@ -501,7 +502,8 @@ enum dwarf_call_frame_info
 
     /* GNU extensions */
     DW_CFA_GNU_window_save = 0x2d,
-    DW_CFA_GNU_args_size = 0x2e
+    DW_CFA_GNU_args_size = 0x2e,
+    DW_CFA_GNU_negative_offset_extended = 0x2f
   };
 
 #define DW_CIE_ID	  0xffffffff
diff --git a/gnu/egcs/gcc/dwarf2out.c b/gnu/egcs/gcc/dwarf2out.c
index de3d26fcb34..30df09d7c28 100644
--- a/gnu/egcs/gcc/dwarf2out.c
+++ b/gnu/egcs/gcc/dwarf2out.c
@@ -719,6 +719,8 @@ dwarf_cfi_name (cfi_opc)
       return "DW_CFA_GNU_window_save";
     case DW_CFA_GNU_args_size:
       return "DW_CFA_GNU_args_size";
+    case DW_CFA_GNU_negative_offset_extended:
+      return "DW_CFA_GNU_negative_offset_extended";
 
     default:
       return "DW_CFA_<unknown>";
@@ -948,7 +950,10 @@ reg_save (label, reg, sreg, offset)
 
       offset /= DWARF_CIE_DATA_ALIGNMENT;
       if (offset < 0)
-	abort ();
+	{
+	  cfi->dw_cfi_opc = DW_CFA_GNU_negative_offset_extended;
+	  offset = -offset;
+	}
       cfi->dw_cfi_oprnd2.dw_cfi_offset = offset;
     }
   else
@@ -1635,6 +1640,7 @@ output_cfi (cfi, fde)
 	  break;
 #endif
 	case DW_CFA_offset_extended:
+	case DW_CFA_GNU_negative_offset_extended:
 	case DW_CFA_def_cfa:
 	  output_uleb128 (cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
           fputc ('\n', asm_out_file);
diff --git a/gnu/egcs/gcc/except.c b/gnu/egcs/gcc/except.c
index f7d78d687ef..cc6fc291345 100644
--- a/gnu/egcs/gcc/except.c
+++ b/gnu/egcs/gcc/except.c
@@ -723,21 +723,41 @@ static void
 receive_exception_label (handler_label)
      rtx handler_label;
 {
+  rtx around_label = NULL_RTX;
+
+  if (! flag_new_exceptions || exceptions_via_longjmp)
+    {
+      around_label = gen_label_rtx ();
+      emit_jump (around_label);
+      emit_barrier ();
+    }
+
   emit_label (handler_label);
   
-#ifdef HAVE_exception_receiver
   if (! exceptions_via_longjmp)
-    if (HAVE_exception_receiver)
-      emit_insn (gen_exception_receiver ());
+    {
+#ifdef HAVE_exception_receiver
+      if (HAVE_exception_receiver)
+       emit_insn (gen_exception_receiver ());
+      else
 #endif
-
 #ifdef HAVE_nonlocal_goto_receiver
-  if (! exceptions_via_longjmp)
-    if (HAVE_nonlocal_goto_receiver)
-      emit_insn (gen_nonlocal_goto_receiver ());
+      if (HAVE_nonlocal_goto_receiver)
+       emit_insn (gen_nonlocal_goto_receiver ());
+      else
 #endif
-}
+       { /* Nothing */ }
+    }
+  else
+    {
+#ifndef DONT_USE_BUILTIN_SETJMP
+      expand_builtin_setjmp_receiver (handler_label);
+#endif
+    }
 
+  if (around_label)
+    emit_label (around_label);
+}
 
 struct func_eh_entry 
 {
@@ -1320,7 +1340,7 @@ static void
 start_dynamic_handler ()
 {
   rtx dhc, dcc;
-  rtx x, arg, buf;
+  rtx arg, buf;
   int size;
 
 #ifndef DONT_USE_BUILTIN_SETJMP
@@ -1362,18 +1382,17 @@ start_dynamic_handler ()
   buf = plus_constant (XEXP (arg, 0), GET_MODE_SIZE (Pmode)*2);
 
 #ifdef DONT_USE_BUILTIN_SETJMP
-  x = emit_library_call_value (setjmp_libfunc, NULL_RTX, 1, SImode, 1,
-			       buf, Pmode);
-  /* If we come back here for a catch, transfer control to the handler.  */
-  jumpif_rtx (x, ehstack.top->entry->exception_handler_label);
-#else
   {
-    /* A label to continue execution for the no exception case.  */
-    rtx noex = gen_label_rtx();
-    x = expand_builtin_setjmp (buf, NULL_RTX, noex,
-			       ehstack.top->entry->exception_handler_label);
-    emit_label (noex);
+    rtx x;
+    x = emit_library_call_value (setjmp_libfunc, NULL_RTX, LCT_CONST,
+                                TYPE_MODE (integer_type_node), 1,
+                                buf, Pmode);
+    /* If we come back here for a catch, transfer control to the handler.  */
+    jumpif_rtx (x, ehstack.top->entry->exception_handler_label);
   }
+#else
+  expand_builtin_setjmp_setup (buf,
+                              ehstack.top->entry->exception_handler_label);
 #endif
 
   /* We are committed to this, so update the handler chain.  */
diff --git a/gnu/egcs/gcc/expmed.c b/gnu/egcs/gcc/expmed.c
index ffe16fedaf4..dd5973dae4b 100644
--- a/gnu/egcs/gcc/expmed.c
+++ b/gnu/egcs/gcc/expmed.c
@@ -4194,9 +4194,11 @@ emit_store_flag (target, code, op0, op1, mode, unsignedp, normalizep)
 	 comparison and then the scc insn.
 
 	 compare_from_rtx may call emit_queue, which would be deleted below
-	 if the scc insn fails.  So call it ourselves before setting LAST.  */
+	 if the scc insn fails.  So call it ourselves before setting LAST.
+	 Likewise for do_pending_stack_adjust.  */
 
       emit_queue ();
+      do_pending_stack_adjust ();
       last = get_last_insn ();
 
       comparison
diff --git a/gnu/egcs/gcc/expr.h b/gnu/egcs/gcc/expr.h
index 55e82e6622d..c279774afe5 100644
--- a/gnu/egcs/gcc/expr.h
+++ b/gnu/egcs/gcc/expr.h
@@ -831,7 +831,8 @@ extern rtx store_expr PROTO((tree, rtx, int));
    Useful after calling expand_expr with 1 as sum_ok.  */
 extern rtx force_operand PROTO((rtx, rtx));
 
-extern rtx expand_builtin_setjmp PROTO((rtx, rtx, rtx, rtx));
+extern void expand_builtin_setjmp_setup PARAMS ((rtx, rtx));
+extern void expand_builtin_setjmp_receiver PARAMS ((rtx));
 
 #ifdef TREE_CODE
 /* Generate code for computing expression EXP.
diff --git a/gnu/egcs/gcc/f/lang-specs.h b/gnu/egcs/gcc/f/lang-specs.h
index b4492a6327d..39afae0c6db 100644
--- a/gnu/egcs/gcc/f/lang-specs.h
+++ b/gnu/egcs/gcc/f/lang-specs.h
@@ -35,7 +35,7 @@ the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA
 	Sun f77, at least) so you test `__unix' rather than `unix'.
 	-D_LANGUAGE_FORTRAN is used by some compilers like SGI and
 	might as well be in there. */
-   {"cpp -lang-c %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
+   {"cpp0 -lang-c %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
 	%{C:%{!E:%eGNU C does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
 	%{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\
@@ -85,7 +85,7 @@ the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA
 		      %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\
 		      %{!pipe:%g.s} %A\n }}}}"}},
   {"@f77-version",
-   {"cpp -lang-c %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I \
+   {"cpp0 -lang-c %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I \
       %{C:%{!E:%eGNU C does not support -C without using -E}} \
       %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} \
       %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2} \
diff --git a/gnu/egcs/gcc/flow.c b/gnu/egcs/gcc/flow.c
index ac8fd6337ff..b9c9d07c5b9 100644
--- a/gnu/egcs/gcc/flow.c
+++ b/gnu/egcs/gcc/flow.c
@@ -1681,7 +1681,7 @@ delete_block (b)
      basic_block b;
 {
   int deleted_handler = 0;
-  rtx insn, end;
+  rtx insn, end, tmp;
 
   /* If the head of this block is a CODE_LABEL, then it might be the
      label for an exception handler which can't be reached.
@@ -1728,11 +1728,21 @@ delete_block (b)
 	}
     }
 
-  /* Selectively unlink the insn chain.  Include any BARRIER that may
-     follow the basic block.  */
-  end = next_nonnote_insn (b->end);
-  if (!end || GET_CODE (end) != BARRIER)
-    end = b->end;
+  /* Include any jump table following the basic block.  */
+  end = b->end;
+  if (GET_CODE (end) == JUMP_INSN
+      && (tmp = JUMP_LABEL (end)) != NULL_RTX
+      && (tmp = NEXT_INSN (tmp)) != NULL_RTX
+      && GET_CODE (tmp) == JUMP_INSN
+      && (GET_CODE (PATTERN (tmp)) == ADDR_VEC
+	  || GET_CODE (PATTERN (tmp)) == ADDR_DIFF_VEC))
+    end = tmp;
+
+  /* Include any barrier that may follow the basic block.  */
+  tmp = next_nonnote_insn (b->end);
+  if (tmp && GET_CODE (tmp) == BARRIER)
+    end = tmp;
+
   delete_insn_chain (insn, end);
 
 no_delete_insns:
@@ -1796,6 +1806,7 @@ flow_delete_insn (insn)
 {
   rtx prev = PREV_INSN (insn);
   rtx next = NEXT_INSN (insn);
+  rtx note;
 
   PREV_INSN (insn) = NULL_RTX;
   NEXT_INSN (insn) = NULL_RTX;
@@ -1815,6 +1826,10 @@ flow_delete_insn (insn)
   if (GET_CODE (insn) == JUMP_INSN && JUMP_LABEL (insn))
     LABEL_NUSES (JUMP_LABEL (insn))--;
 
+  /* Also if deleting an insn that references a label.  */
+  else if ((note = find_reg_note (insn, REG_LABEL, NULL_RTX)) != NULL_RTX)
+    LABEL_NUSES (XEXP (note, 0))--;
+
   return next;
 }
 
@@ -2721,6 +2736,39 @@ propagate_block (old, first, last, final, significant, bnum, remove_dead_code)
 	     can cause trouble for first or last insn in a basic block.  */
 	  if (final && insn_is_dead)
 	    {
+	      rtx inote;
+	      /* If the insn referred to a label, note that the label is
+		 now less used.  */
+	      for (inote = REG_NOTES (insn); inote; inote = XEXP (inote, 1))
+		{
+		  if (REG_NOTE_KIND (inote) == REG_LABEL)
+		    {
+		      rtx label = XEXP (inote, 0);
+		      rtx next;
+		      LABEL_NUSES (label)--;
+
+		      /* If this label was attached to an ADDR_VEC, it's
+			 safe to delete the ADDR_VEC.  In fact, it's pretty much
+			 mandatory to delete it, because the ADDR_VEC may
+			 be referencing labels that no longer exist.  */
+		      if (LABEL_NUSES (label) == 0
+			  && (next = next_nonnote_insn (label)) != NULL
+			  && GET_CODE (next) == JUMP_INSN
+			  && (GET_CODE (PATTERN (next)) == ADDR_VEC
+			      || GET_CODE (PATTERN (next)) == ADDR_DIFF_VEC))
+			{
+			  rtx pat = PATTERN (next);
+			  int diff_vec_p = GET_CODE (pat) == ADDR_DIFF_VEC;
+			  int len = XVECLEN (pat, diff_vec_p);
+			  int i;
+			  for (i = 0; i < len; i++)
+			    LABEL_NUSES (XEXP (XVECEXP (pat, diff_vec_p, i), 0))--;
+
+			  flow_delete_insn (next);
+			}
+		    }
+		}
+
 	      PUT_CODE (insn, NOTE);
 	      NOTE_LINE_NUMBER (insn) = NOTE_INSN_DELETED;
 	      NOTE_SOURCE_FILE (insn) = 0;
diff --git a/gnu/egcs/gcc/frame.c b/gnu/egcs/gcc/frame.c
index b5f643e7043..4dabf119b82 100644
--- a/gnu/egcs/gcc/frame.c
+++ b/gnu/egcs/gcc/frame.c
@@ -714,6 +714,14 @@ execute_cfa_insn (void *p, struct frame_state_internal *state,
       state->s.args_size = offset;
       break;
 
+    case DW_CFA_GNU_negative_offset_extended:
+      p = decode_uleb128 (p, &reg);
+      p = decode_uleb128 (p, &offset);
+      offset *= info->data_align;
+      state->s.saved[reg] = REG_SAVED_OFFSET;
+      state->s.reg_or_offset[reg] = -offset;
+      break;
+
     default:
       abort ();
     }
diff --git a/gnu/egcs/gcc/just-fixinc b/gnu/egcs/gcc/just-fixinc
index 4c51043cf50..dc7695f6ad1 100644
--- a/gnu/egcs/gcc/just-fixinc
+++ b/gnu/egcs/gcc/just-fixinc
@@ -1,5 +1,5 @@
 #!/bin/sh
-# $Id: just-fixinc,v 1.1.1.4 2000/09/24 23:21:00 espie Exp $
+# $Id: just-fixinc,v 1.1.1.5 2001/01/29 15:12:56 espie Exp $
 # This script exists for use after installing
 # the GCC binaries from a distribution tape/CD-ROM.
 # Use it *after* copying the directory of binaries
diff --git a/gnu/egcs/gcc/mkinstalldirs b/gnu/egcs/gcc/mkinstalldirs
index a36083aaaea..f997b456f1d 100644
--- a/gnu/egcs/gcc/mkinstalldirs
+++ b/gnu/egcs/gcc/mkinstalldirs
@@ -4,7 +4,7 @@
 # Created: 1993-05-16
 # Public domain
 
-# $Id: mkinstalldirs,v 1.1.1.4 2000/09/24 23:21:04 espie Exp $
+# $Id: mkinstalldirs,v 1.1.1.5 2001/01/29 15:13:04 espie Exp $
 
 errstatus=0
 
diff --git a/gnu/egcs/gcc/objc/lang-specs.h b/gnu/egcs/gcc/objc/lang-specs.h
index 41dc097b502..b0d873144c3 100644
--- a/gnu/egcs/gcc/objc/lang-specs.h
+++ b/gnu/egcs/gcc/objc/lang-specs.h
@@ -24,7 +24,7 @@ Boston, MA 02111-1307, USA.  */
   {".m", {"@objective-c"}},
   {"@objective-c",
 #if USE_CPPLIB
-   {"%{E|M|MM:cpp -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
+   {"%{E|M|MM:cpp0 -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
 	%{C:%{!E:%eGNU C does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
         -D__OBJC__ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\
@@ -55,7 +55,7 @@ Boston, MA 02111-1307, USA.  */
 	%{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\
         %{!pipe:%g.s} %A\n }}}}"}
 #else /* ! USE_CPPLIB */
-   {"cpp -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
+   {"cpp0 -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\
 	%{C:%{!E:%eGNU C does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
         -D__OBJC__ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\
diff --git a/gnu/egcs/gcc/reload.c b/gnu/egcs/gcc/reload.c
index d8b41363d36..5b828670df2 100644
--- a/gnu/egcs/gcc/reload.c
+++ b/gnu/egcs/gcc/reload.c
@@ -322,7 +322,6 @@ static int find_reusable_reload	PROTO((rtx *, rtx, enum reg_class,
 static rtx find_dummy_reload	PROTO((rtx, rtx, rtx *, rtx *,
 				       enum machine_mode, enum machine_mode,
 				       enum reg_class, int, int));
-static int earlyclobber_operand_p PROTO((rtx));
 static int hard_reg_set_here_p	PROTO((int, int, rtx));
 static struct decomposition decompose PROTO((rtx));
 static int immune_p		PROTO((rtx, rtx, struct decomposition));
@@ -591,7 +590,13 @@ push_secondary_reload (in_p, x, opnum, optional, reload_class, reload_mode,
 
       if (in_p && icode == CODE_FOR_nothing
 	  && SECONDARY_MEMORY_NEEDED (class, reload_class, mode))
-	get_secondary_mem (x, reload_mode, opnum, type);
+	{
+	  get_secondary_mem (x, reload_mode, opnum, type);
+
+	  /* We may have just added new reloads.  Make sure we add
+	     the new reload at the end.  */
+	  s_reload = n_reloads;
+	}
 #endif
 
       /* We need to make a new secondary reload for this register class.  */
@@ -1529,12 +1534,23 @@ push_reload (in, out, inloc, outloc, class,
 	    && GET_MODE_SIZE (inmode) <= GET_MODE_SIZE (GET_MODE (XEXP (note, 0)))
 	    && HARD_REGNO_MODE_OK (regno, inmode)
 	    && GET_MODE_SIZE (outmode) <= GET_MODE_SIZE (GET_MODE (XEXP (note, 0)))
-	    && HARD_REGNO_MODE_OK (regno, outmode)
-	    && TEST_HARD_REG_BIT (reg_class_contents[(int) class], regno)
-	    && !fixed_regs[regno])
+	    && HARD_REGNO_MODE_OK (regno, outmode))
 	  {
-	    reload_reg_rtx[i] = gen_rtx_REG (inmode, regno);
-	    break;
+	    unsigned int offs;
+	    unsigned int nregs = MAX (HARD_REGNO_NREGS (regno, inmode),
+				      HARD_REGNO_NREGS (regno, outmode));
+
+	    for (offs = 0; offs < nregs; offs++)
+	      if (fixed_regs[regno + offs]
+		  || ! TEST_HARD_REG_BIT (reg_class_contents[(int) class],
+					  regno + offs))
+		break;
+
+	    if (offs == nregs)
+	      {
+		reload_reg_rtx[i] = gen_rtx_REG (inmode, regno);
+		break;
+	      }
 	  }
     }
 
@@ -1989,7 +2005,7 @@ find_dummy_reload (real_in, real_out, inloc, outloc,
 
 /* Return 1 if X is an operand of an insn that is being earlyclobbered.  */
 
-static int
+int
 earlyclobber_operand_p (x)
      rtx x;
 {
@@ -4666,7 +4682,7 @@ find_reloads_address (mode, memrefloc, ad, loc, opnum, type, ind_levels, insn)
 
       else if (regno < FIRST_PSEUDO_REGISTER
 	       && REGNO_MODE_OK_FOR_BASE_P (regno, mode)
-	       && ! regno_clobbered_p (regno, this_insn))
+	       && ! regno_clobbered_p (regno, this_insn, GET_MODE (ad), 0))
 	return 0;
 
       /* If we do not have one of the cases above, we must do the reload.  */
@@ -5346,7 +5362,12 @@ find_reloads_address_1 (mode, x, context, loc, opnum, type, ind_levels, insn)
 			&& (*insn_operand_predicate[icode][0]) (equiv, Pmode)
 			&& (*insn_operand_predicate[icode][1]) (equiv, Pmode)))
 		{
-		  loc = &XEXP (x, 0);
+		  /* We use the original pseudo for loc, so that
+		     emit_reload_insns() knows which pseudo this
+		     reload refers to and updates the pseudo rtx, not
+		     its equivalent memory location, as well as the
+		     corresponding entry in reg_last_reload_reg.  */
+		  loc = &XEXP (x_orig, 0);
 		  x = XEXP (x, 0);
 		  reloadnum
 		    = push_reload (x, x, loc, loc,
@@ -5354,13 +5375,6 @@ find_reloads_address_1 (mode, x, context, loc, opnum, type, ind_levels, insn)
 				    GET_MODE (x), GET_MODE (x), 0, 0,
 				    opnum, RELOAD_OTHER);
 
-		  /* If we created a new MEM based on reg_equiv_mem[REGNO], then
-		     LOC above is part of the new MEM, not the MEM in INSN.
-
-		     We must also replace the address of the MEM in INSN.  */
-		  if (&XEXP (x_orig, 0) != loc)
-		    push_replacement (&XEXP (x_orig, 0), reloadnum, VOIDmode);
-
 		}
 	      else
 		{
@@ -5500,7 +5514,7 @@ find_reloads_address_1 (mode, x, context, loc, opnum, type, ind_levels, insn)
 	   in this insn, reload it into some other register to be safe.
 	   The CLOBBER is supposed to make the register unavailable
 	   from before this insn to after it.  */
-	if (regno_clobbered_p (regno, this_insn))
+	if (regno_clobbered_p (regno, this_insn, GET_MODE (x), 0))
 	  {
 	    push_reload (x, NULL_RTX, loc, NULL_PTR,
 			 (context ? INDEX_REG_CLASS : BASE_REG_CLASS),
@@ -6260,16 +6274,29 @@ find_equiv_reg (goal, insn, class, other, reload_reg_p, goalreg, mode)
 		      && (valtry
 			  = operand_subword (SET_DEST (pat), 1, 0, VOIDmode))
 		      && (valueno = true_regnum (valtry)) >= 0)))
-	    if (other >= 0
-		? valueno == other
-		: ((unsigned) valueno < FIRST_PSEUDO_REGISTER
-		   && TEST_HARD_REG_BIT (reg_class_contents[(int) class],
-					 valueno)))
-	      {
-		value = valtry;
-		where = p;
-		break;
-	      }
+	    {
+	      if (other >= 0)
+		{
+		  if (valueno != other)
+		    continue;
+		}
+	      else if ((unsigned) valueno >= FIRST_PSEUDO_REGISTER)
+		continue;
+	      else
+		{
+		  int i;
+
+		  for (i = HARD_REGNO_NREGS (valueno, mode) - 1; i >= 0; i--)
+		    if (! TEST_HARD_REG_BIT (reg_class_contents[(int) class],
+					     valueno + i))
+		      break;
+		  if (i >= 0)
+		    continue;
+		}
+	      value = valtry;
+	      where = p;
+	      break;
+	    }
 	}
     }
 
@@ -6312,15 +6339,22 @@ find_equiv_reg (goal, insn, class, other, reload_reg_p, goalreg, mode)
       && regno < valueno + HARD_REGNO_NREGS (valueno, mode))
     return 0;
 
+  nregs = HARD_REGNO_NREGS (regno, mode);
+  valuenregs = HARD_REGNO_NREGS (valueno, mode);
+
   /* Reject VALUE if it is one of the regs reserved for reloads.
      Reload1 knows how to reuse them anyway, and it would get
      confused if we allocated one without its knowledge.
      (Now that insns introduced by reload are ignored above,
      this case shouldn't happen, but I'm not positive.)  */
 
-  if (reload_reg_p != 0 && reload_reg_p != (short *) (HOST_WIDE_INT) 1
-      && reload_reg_p[valueno] >= 0)
-    return 0;
+  if (reload_reg_p != 0 && reload_reg_p != (short *) (HOST_WIDE_INT) 1)
+    {
+      int i;
+      for (i = 0; i < valuenregs; ++i)
+	if (reload_reg_p[valueno + i] >= 0)
+	  return 0;
+    }
 
   /* On some machines, certain regs must always be rejected
      because they don't behave the way ordinary registers do.  */
@@ -6330,9 +6364,6 @@ find_equiv_reg (goal, insn, class, other, reload_reg_p, goalreg, mode)
     return 0;
 #endif      
 
-  nregs = HARD_REGNO_NREGS (regno, mode);
-  valuenregs = HARD_REGNO_NREGS (valueno, mode);
-
   /* Reject VALUE if it is a register being used for an input reload
      even if it is not one of those reserved.  */
 
@@ -6368,16 +6399,23 @@ find_equiv_reg (goal, insn, class, other, reload_reg_p, goalreg, mode)
 
       /* Don't trust the conversion past a function call
 	 if either of the two is in a call-clobbered register, or memory.  */
-      if (GET_CODE (p) == CALL_INSN
-	  && ((regno >= 0 && regno < FIRST_PSEUDO_REGISTER
-	       && call_used_regs[regno])
-	      ||
-	      (valueno >= 0 && valueno < FIRST_PSEUDO_REGISTER
-	       && call_used_regs[valueno])
-	      ||
-	      goal_mem
-	      || need_stable_sp))
-	return 0;
+      if (GET_CODE (p) == CALL_INSN)
+	{
+	  int i;
+
+	  if (goal_mem || need_stable_sp)
+	    return 0;
+
+	  if (regno >= 0 && regno < FIRST_PSEUDO_REGISTER)
+	    for (i = 0; i < nregs; ++i)
+	      if (call_used_regs[regno + i])
+		return 0;
+
+	  if (valueno >= 0 && valueno < FIRST_PSEUDO_REGISTER)
+	    for (i = 0; i < valuenregs; ++i)
+	      if (call_used_regs[valueno + i])
+		return 0;
+	}
 
 #ifdef NON_SAVING_SETJMP 
       if (NON_SAVING_SETJMP && GET_CODE (p) == NOTE
@@ -6613,13 +6651,23 @@ find_inc_amount (x, inced)
 /* Return 1 if register REGNO is the subject of a clobber in insn INSN.  */
 
 int
-regno_clobbered_p (regno, insn)
+regno_clobbered_p (regno, insn, mode, sets)
      int regno;
      rtx insn;
+     enum machine_mode mode;
+     int sets;
 {
-  if (GET_CODE (PATTERN (insn)) == CLOBBER
+  int nregs = HARD_REGNO_NREGS (regno, mode);
+  int endregno = regno + nregs;
+
+  if ((GET_CODE (PATTERN (insn)) == CLOBBER
+       || (sets && GET_CODE (PATTERN (insn)) == SET))
       && GET_CODE (XEXP (PATTERN (insn), 0)) == REG)
-    return REGNO (XEXP (PATTERN (insn), 0)) == regno;
+    {
+      int test = REGNO (XEXP (PATTERN (insn), 0));
+
+      return test >= regno && test < endregno;
+    }
 
   if (GET_CODE (PATTERN (insn)) == PARALLEL)
     {
@@ -6628,9 +6676,15 @@ regno_clobbered_p (regno, insn)
       for (; i >= 0; i--)
 	{
 	  rtx elt = XVECEXP (PATTERN (insn), 0, i);
-	  if (GET_CODE (elt) == CLOBBER && GET_CODE (XEXP (elt, 0)) == REG
-	      && REGNO (XEXP (elt, 0)) == regno)
-	    return 1;
+	  if ((GET_CODE (elt) == CLOBBER
+	       || (sets && GET_CODE (PATTERN (insn)) == SET))
+	      && GET_CODE (XEXP (elt, 0)) == REG)
+	    {
+	      int test = REGNO (XEXP (elt, 0));
+	      
+	      if (test >= regno && test < endregno)
+		return 1;
+	    }
 	}
     }
 
diff --git a/gnu/egcs/gcc/reload.h b/gnu/egcs/gcc/reload.h
index 968d3124af4..7bc6ccab89a 100644
--- a/gnu/egcs/gcc/reload.h
+++ b/gnu/egcs/gcc/reload.h
@@ -296,7 +296,7 @@ extern rtx find_equiv_reg PROTO((rtx, rtx, enum reg_class, int, short *,
 				 int, enum machine_mode));
 
 /* Return 1 if register REGNO is the subject of a clobber in insn INSN.  */
-extern int regno_clobbered_p PROTO((int, rtx));
+extern int regno_clobbered_p PROTO((int, rtx, enum machine_mode, int));
 
 /* Functions in reload1.c:  */
 
@@ -342,3 +342,5 @@ extern void save_call_clobbered_regs PROTO((void));
 
 /* Replace (subreg (reg)) with the appropriate (reg) for any operands.  */
 extern void cleanup_subreg_operands PROTO ((rtx));
+
+extern int earlyclobber_operand_p PROTO((rtx));
diff --git a/gnu/egcs/gcc/rtlanal.c b/gnu/egcs/gcc/rtlanal.c
index fb4f87c07de..49131a4efed 100644
--- a/gnu/egcs/gcc/rtlanal.c
+++ b/gnu/egcs/gcc/rtlanal.c
@@ -2289,3 +2289,82 @@ auto_inc_p (x)
     }
   return 0;
 }
+
+/* Return 1 if the sequence of instructions beginning with FROM and up
+   to and including TO is safe to move.  If NEW_TO is non-NULL, and
+   the sequence is not already safe to move, but can be easily
+   extended to a sequence which is safe, then NEW_TO will point to the
+   end of the extended sequence.  
+ 
+   For now, this function only checks that the region contains whole
+   exception regiongs, but it could be extended to check additional
+   conditions as well.  */
+
+int
+insns_safe_to_move_p (from, to, new_to)
+     rtx from;
+     rtx to;
+     rtx *new_to;
+{
+  int eh_region_count = 0;
+  int past_to_p = 0;
+  rtx r = from;
+
+  /* By default, assume the end of the region will be what was
+     suggested.  */
+  if (new_to)
+    *new_to = to;
+
+  while (r)
+    {
+      if (GET_CODE (r) == NOTE)
+	{
+	  switch (NOTE_LINE_NUMBER (r))
+	    {
+	    case NOTE_INSN_EH_REGION_BEG:
+	      ++eh_region_count;
+	      break;
+
+	    case NOTE_INSN_EH_REGION_END:
+	      if (eh_region_count == 0)
+		/* This sequence of instructions contains the end of
+		   an exception region, but not he beginning.  Moving
+		   it will cause chaos.  */
+		return 0;
+
+	      --eh_region_count;
+	      break;
+
+	    default:
+	      break;
+	    }
+	}
+      else if (past_to_p)
+	/* If we've passed TO, and we see a non-note instruction, we
+	   can't extend the sequence to a movable sequence.  */
+	return 0;
+
+      if (r == to)
+	{
+	  if (!new_to)
+	    /* It's OK to move the sequence if there were matched sets of
+	       exception region notes.  */
+	    return eh_region_count == 0;
+	  
+	  past_to_p = 1;
+	}
+
+      /* It's OK to move the sequence if there were matched sets of
+	 exception region notes.  */
+      if (past_to_p && eh_region_count == 0)
+	{
+	  *new_to = r;
+	  return 1;
+	}
+
+      /* Go to the next instruction.  */
+      r = NEXT_INSN (r);
+    }
+  
+  return 0;
+}
diff --git a/gnu/egcs/gcc/tree.c b/gnu/egcs/gcc/tree.c
index 5e29d2f9115..b6cdf7bebf8 100644
--- a/gnu/egcs/gcc/tree.c
+++ b/gnu/egcs/gcc/tree.c
@@ -1121,6 +1121,26 @@ make_node (code)
     case 'c':
       TREE_CONSTANT (t) = 1;
       break;
+
+     case 'e':
+      switch (code)
+	{
+	case INIT_EXPR:
+	case MODIFY_EXPR:
+	case RTL_EXPR:
+	case PREDECREMENT_EXPR:
+	case PREINCREMENT_EXPR:
+	case POSTDECREMENT_EXPR:
+	case POSTINCREMENT_EXPR:
+	  /* All of these have side-effects, no matter what their
+	     operands are.  */
+	  TREE_SIDE_EFFECTS (t) = 1;
+	  break;
+
+	default:
+	  break;
+	}
+      break;
     }
 
   return t;
@@ -3107,6 +3127,24 @@ build1 (code, type, node)
 	TREE_RAISES (t) = 1;
     }
 
+  switch (code)
+    {
+     case INIT_EXPR:
+     case MODIFY_EXPR:
+     case RTL_EXPR:
+     case PREDECREMENT_EXPR:
+     case PREINCREMENT_EXPR:
+     case POSTDECREMENT_EXPR:
+     case POSTINCREMENT_EXPR:
+      /* All of these have side-effects, no matter what their
+       operands are.  */
+      TREE_SIDE_EFFECTS (t) = 1;
+      break;
+
+     default:
+      break;
+    }
+
   return t;
 }