Analysis of remaining EGCS references 2

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

The following is an analysis of those EGCS references that remain in GCC
and could/should be removed.

./contrib/release:  egcs-1.0*)
./contrib/release:  egcs-1.1*)
./contrib/release:    echo "No java or chill in egcs-1.1*"
./contrib/release:  rm -rf egcs
./contrib/release:  cvs -Q rtag -d $release_tag egcs
./contrib/release:  cvs -Q co -r $release_branch egcs
./contrib/release:  rm -rf egcs
./contrib/release:  zcat ~ftp/pub/gcc/snapshots/egcs-1.1.2-prerelease/$last_release_name.tar.gz | tar xf -
./contrib/release:# Files/directories which are not part of the egcs-core module.
./contrib/release:# Get the egcs core.  Note that the egcs-core module doesn't work yet, so
./contrib/release:cvs -Q export -ko -r$release_tag egcs
./contrib/release:cd egcs
./contrib/release:mv egcs $release_name
./contrib/release:  zcat ~ftp/pub/gcc/snapshots/egcs-1.1.2-prerelease/$last_release_name.tar.gz | tar xf -
./contrib/release:cvs -Q export -ko -r$release_tag egcs
./contrib/release:cd egcs
./contrib/release:mv egcs $release_name

This is a regression from last time (a testcase is needed :-)).  I don't
think there's any current need for the release script to reference EGCS -
since in other ways it's out of date for 3.0 (e.g. including the old
faq.html rather than somehow exporting the FOM contents), I presume this
will all be fixed in the run up to 3.0.

(Incidentally, this script is incomplete.  Everything needed for building
snapshots and releases of GCC should be in CVS.  The following (at least)
seem to be missing: update_changelogs, release_docs.  Similarly, all the
relevant crontabs (nightly update of version dates etc.) should be in CVS
as well.)

./gcc/NEWS:Noteworthy changes in GCC after EGCS 1.1.

The problems of out-of-date NEWS files versus online release notes remain
to be resolved.

./gcc/f/RELEASE-PREP:Things to do to prepare a g77 release (FSF, egcs, whatever).

Somewhere, perhaps there should be a general list of what needs to be done
to produce a new GCC release (including every single place where any
version number or status information lurks).

./gcc/f/g77.texi:This option is obsolete in @code{egcs}

"is obsolete in egcs" suggests egcs as current - perhaps "was obsolete as
of egcs 1.1".

./gcc/f/g77install.texi:and @code{egcs} version 1.0.
./gcc/f/g77install.texi:and version 1.1 of @code{egcs}.
./gcc/f/g77install.texi:and version 1.1 of @code{egcs},
./gcc/f/g77install.texi:and @code{egcs} version 1.1,
./gcc/f/g77install.texi:(This is improved in the @code{egcs} version of @code{g77},

This file will hopefully vanish into the unified instructions, but all
parts conditioned out for current g77 can probably be removed outright -
there's no need now to support building variant g77 documentation for
EGCS/FSF versions, only for the g77 in GCC.  (Likewise the DOC-INSTALL
support can go, as f/INSTALL already has.)

./gcc/f/lang-options.h:/* Use of FTNOPT makes tracking changes between FSF-g77 and egcs-g77

Such tracking no longer needed - so probably a macro no longer needed here
either now g77 is part of GCC (only).

./gcc/f/root.texi:@c EGCS-G77 indicates this is the EGCS (1.0 or 1.1) version of g77.
./gcc/f/root.texi:@clear EGCS-G77

Support no longer needed for EGCS-G77 and FSF-G77.

./gcc/makefile.vms:# makefile for egcs
./gcc/makefile.vms:# choose egcs or dec c

I've proposed before to remove this file unless someone wishes to
resurrect VMS support.  If anyone does, it would still probably make a lot
more sense to keep it in sync with the support for Unix-like systems by
using a Unix-like environment on VMS (if there is one) to use the Unix
build system.

./gcc/config/alpha/openbsd.h:   dwarf unwind information. egcs doesn't try too hard to check internal
./gcc/config/alpha/openbsd.h:   Check alpha/alpha.h, alpha/osf.h for it when egcs is upgraded.  */
./gcc/config/i370/i370.md:;; Basically, using clobber in egcs-1.1.1 will ruin ability to optimize around
./gcc/config/i386/openbsd.h:   dwarf unwind information. egcs doesn't try too hard to check internal
./gcc/config/m68k/openbsd.h:   dwarf unwind information. egcs doesn't try too hard to check internal
./gcc/config/m68k/x-mot3300:# With egcs-1.1.2, this also happens for f/expr.o and f/stb.o
./gcc/config/ns32k/ns32k.h:   2.8 but was not picked up by egcs (at least egcs 1.0). Having all
./gcc/config/sparc/openbsd.h:   dwarf unwind information. egcs doesn't try too hard to check internal

All these comments should be checked for applicability to current GCC, and
updated if appropriate.

./libio/NEWS:*** Major changes in libio for egcs:
./libstdc++/NEWS:*** Noteworthy changes in libstdc++ for EGCS
./libstdc++/NEWS:* EGCS includes the SGI STL implementation without changes.
./libstdc++/NEWS:* As a result of these and other changes, libstc++ for EGCS is not binary

Will the old libstdc++ stay around at all (as a non-default option) or
will these be disappearing at some point?

./libstdc++-v3/docs/17_intro/BADNAMES:For egcs:

The list, if it relates to some EGCS version (predating GCC 2.95), may
need updating to one that genuinely relates to current GCC, before this
reference changes.

./texinfo/INSTALL:Note most of this information is out of date and superceded by the EGCS
./texinfo/Makefile.am:# ??? For EGCS, only build the stuff we actually need.  This eliminates the
./texinfo/Makefile.in:# ??? For EGCS, only build the stuff we actually need.  This eliminates the
./texinfo/aclocal.m4:AC_DEFUN(EGCS_PROG_INSTALL,
./texinfo/configure.in:EGCS_PROG_INSTALL

What's the status of removal of texinfo from GCC?  Is the work still
needed to install generated info files from srcdir if makeinfo isn't
available?

-- 
Joseph S. Myers
jsm28@cam.ac.uk