us to track which bugs have been fixed and to forward your bugs reports
to the appropriate maintainer.
-Do not compress and encode any part of your bug report using programs
-such as @file{uuencode}. If you do so it will slow down the processing
-of your bug. If you must submit multiple large files, use @file{shar},
-which allows us to read your message without having to run any
-decompression programs.
+If you include source code in your message, you can send it as clear
+text if it is small. If the message is larger, you may compress it using
+@file{gzip}, @file{bzip2}, or @file{pkzip}. Please be aware that sending
+compressed files needs an additional binary-safe mechanism such as
+@code{MIME} or @code{uuencode}. There is a 40k message limit on the
+@samp{egcs-bugs@@cygnus.com} mailing list at the time of this writing
+(August 1998).
To enable someone to investigate the bug, you should include all these
things:
@item
A complete input file that will reproduce the bug. If the bug is in the
C preprocessor, send a source file and any header files that it
-requires. If the bug is in the compiler proper (@file{cc1}), run your
-source file through the C preprocessor by doing @samp{gcc -E
-@var{sourcefile} > @var{outfile}}, then include the contents of
-@var{outfile} in the bug report. (When you do this, use the same
-@samp{-I}, @samp{-D} or @samp{-U} options that you used in actual
-compilation.)
+requires. If the bug is in the compiler proper (@file{cc1}), send the
+preprocessor output generated by adding @samp{-save-temps} to the
+compilation command (@pxref{Debugging Options}). When you do this, use
+the same @samp{-I}, @samp{-D} or @samp{-U} options that you used in
+actual compilation. Then send the @var{input}.i or @var{input}.ii files
+generated.
A single statement is not enough of an example. In order to compile it,
it must be embedded in a complete file of compiler input; and the bug