1 files changed, 0 insertions, 94 deletions
diff --git a/gcc-4.2.1-5666.3/gcc/doc/bugreport.texi b/gcc-4.2.1-5666.3/gcc/doc/bugreport.texi
deleted file mode 100644
index 9e10af910..000000000
--- a/gcc-4.2.1-5666.3/gcc/doc/bugreport.texi
+++ /dev/null
@@ -1,94 +0,0 @@
-@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-@c 1999, 2000, 2001, 2003, 2004 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Bugs
-@chapter Reporting Bugs
-@cindex bugs
-@cindex reporting bugs
-
-Your bug reports play an essential role in making GCC reliable.
-
-When you encounter a problem, the first thing to do is to see if it is
-already known.  @xref{Trouble}.  If it isn't known, then you should
-report the problem.
-
-@menu
-* Criteria:  Bug Criteria.   Have you really found a bug?
-* Reporting: Bug Reporting.  How to report a bug effectively.
-* Known: Trouble.            Known problems.
-* Help: Service.             Where to ask for help.
-@end menu
-
-@node Bug Criteria,Bug Reporting,,Bugs
-@section Have You Found a Bug?
-@cindex bug criteria
-
-If you are not sure whether you have found a bug, here are some guidelines:
-
-@itemize @bullet
-@cindex fatal signal
-@cindex core dump
-@item
-If the compiler gets a fatal signal, for any input whatever, that is a
-compiler bug.  Reliable compilers never crash.
-
-@cindex invalid assembly code
-@cindex assembly code, invalid
-@item
-If the compiler produces invalid assembly code, for any input whatever
-(except an @code{asm} statement), that is a compiler bug, unless the
-compiler reports errors (not just warnings) which would ordinarily
-prevent the assembler from being run.
-
-@cindex undefined behavior
-@cindex undefined function value
-@cindex increment operators
-@item
-If the compiler produces valid assembly code that does not correctly
-execute the input source code, that is a compiler bug.
-
-However, you must double-check to make sure, because you may have a
-program whose behavior is undefined, which happened by chance to give
-the desired results with another C or C++ compiler.
-
-For example, in many nonoptimizing compilers, you can write @samp{x;}
-at the end of a function instead of @samp{return x;}, with the same
-results.  But the value of the function is undefined if @code{return}
-is omitted; it is not a bug when GCC produces different results.
-
-Problems often result from expressions with two increment operators,
-as in @code{f (*p++, *p++)}.  Your previous compiler might have
-interpreted that expression the way you intended; GCC might
-interpret it another way.  Neither compiler is wrong.  The bug is
-in your code.
-
-After you have localized the error to a single source line, it should
-be easy to check for these things.  If your program is correct and
-well defined, you have found a compiler bug.
-
-@item
-If the compiler produces an error message for valid input, that is a
-compiler bug.
-
-@cindex invalid input
-@item
-If the compiler does not produce an error message for invalid input,
-that is a compiler bug.  However, you should note that your idea of
-``invalid input'' might be someone else's idea of ``an extension'' or
-``support for traditional practice''.
-
-@item
-If you are an experienced user of one of the languages GCC supports, your
-suggestions for improvement of GCC are welcome in any case.
-@end itemize
-
-@node Bug Reporting,,Bug Criteria,Bugs
-@section How and where to Report Bugs
-@cindex compiler bugs, reporting
-
-Bugs should be reported to the GCC bug database.  Please refer to
-@uref{http://gcc.gnu.org/bugs.html} for up-to-date instructions how to
-submit bug reports.  Copies of this file in HTML (@file{bugs.html}) and
-plain text (@file{BUGS}) are also part of GCC releases.