711 lines
34 KiB
HTML
711 lines
34 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on March, 17 2001 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>Using and Porting the GNU Compiler Collection (GCC): Bugs</TITLE>
|
|
|
|
<META NAME="description" CONTENT="Using and Porting the GNU Compiler Collection (GCC): Bugs">
|
|
<META NAME="keywords" CONTENT="Using and Porting the GNU Compiler Collection (GCC): Bugs">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC135"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_7.html#SEC134" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC134"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC136" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC136"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 8. Reporting Bugs </H1>
|
|
<!--docid::SEC135::-->
|
|
<P>
|
|
|
|
Your bug reports play an essential role in making GCC reliable.
|
|
</P><P>
|
|
|
|
When you encounter a problem, the first thing to do is to see if it is
|
|
already known. See section <A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118">7. Known Causes of Trouble with GCC</A>. If it isn't known, then you should
|
|
report the problem.
|
|
</P><P>
|
|
|
|
Reporting a bug may help you by bringing a solution to your problem, or
|
|
it may not. (If it does not, look in the service directory; see
|
|
<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140">9. How To Get Help with GCC</A>.) In any case, the principal function of a bug report is
|
|
to help the entire community by making the next version of GCC work
|
|
better. Bug reports are your contribution to the maintenance of GCC.
|
|
</P><P>
|
|
|
|
Since the maintainers are very overloaded, we cannot respond to every
|
|
bug report. However, if the bug has not been fixed, we are likely to
|
|
send you a patch and ask you to tell us whether it works.
|
|
</P><P>
|
|
|
|
In order for a bug report to serve its purpose, you must include the
|
|
information that makes for fixing the bug.
|
|
</P><P>
|
|
|
|
<BLOCKQUOTE><TABLE BORDER=0 CELLSPACING=0>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_8.html#SEC136" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC136">8.1 Have You Found a Bug?</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Have you really found a bug?</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_8.html#SEC137" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC137">8.2 Where to Report Bugs</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Where to send your bug report.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_8.html#SEC138" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC138">8.3 How to Report Bugs</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">How to report a bug effectively.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_8.html#SEC139" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC139">8.4 Sending Patches for GCC</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">How to send a patch for GCC.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_7.html#SEC118" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC118">7. Known Causes of Trouble with GCC</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Known problems.</TD></TR>
|
|
<TR><TD ALIGN="left" VALIGN="TOP"><A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140">9. How To Get Help with GCC</A></TD><TD> </TD><TD ALIGN="left" VALIGN="TOP">Where to ask for help.</TD></TR>
|
|
</TABLE></BLOCKQUOTE>
|
|
<P>
|
|
|
|
<A NAME="Bug Criteria"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC136"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC137" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC137"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 8.1 Have You Found a Bug? </H2>
|
|
<!--docid::SEC136::-->
|
|
<P>
|
|
|
|
If you are not sure whether you have found a bug, here are some guidelines:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<A NAME="IDX405"></A>
|
|
<A NAME="IDX406"></A>
|
|
<LI>
|
|
If the compiler gets a fatal signal, for any input whatever, that is a
|
|
compiler bug. Reliable compilers never crash.
|
|
<P>
|
|
|
|
<A NAME="IDX407"></A>
|
|
<A NAME="IDX408"></A>
|
|
<LI>
|
|
If the compiler produces invalid assembly code, for any input whatever
|
|
(except an <CODE>asm</CODE> statement), that is a compiler bug, unless the
|
|
compiler reports errors (not just warnings) which would ordinarily
|
|
prevent the assembler from being run.
|
|
<P>
|
|
|
|
<A NAME="IDX409"></A>
|
|
<A NAME="IDX410"></A>
|
|
<A NAME="IDX411"></A>
|
|
<LI>
|
|
If the compiler produces valid assembly code that does not correctly
|
|
execute the input source code, that is a compiler bug.
|
|
<P>
|
|
|
|
However, you must double-check to make sure, because you may have run
|
|
into an incompatibility between GNU C and traditional C
|
|
(see section <A HREF="gcc_7.html#SEC124" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_7.html#SEC124">7.6 Incompatibilities of GCC</A>). These incompatibilities might be considered
|
|
bugs, but they are inescapable consequences of valuable features.
|
|
</P><P>
|
|
|
|
Or you may have a program whose behavior is undefined, which happened
|
|
by chance to give the desired results with another C or C++ compiler.
|
|
</P><P>
|
|
|
|
For example, in many nonoptimizing compilers, you can write <SAMP>`x;'</SAMP>
|
|
at the end of a function instead of <SAMP>`return x;'</SAMP>, with the same
|
|
results. But the value of the function is undefined if <CODE>return</CODE>
|
|
is omitted; it is not a bug when GCC produces different results.
|
|
</P><P>
|
|
|
|
Problems often result from expressions with two increment operators,
|
|
as in <CODE>f (*p++, *p++)</CODE>. 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.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
<LI>
|
|
If the compiler produces an error message for valid input, that is a
|
|
compiler bug.
|
|
<P>
|
|
|
|
<A NAME="IDX412"></A>
|
|
<LI>
|
|
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 my idea of "an extension" or "support
|
|
for traditional practice".
|
|
<P>
|
|
|
|
<LI>
|
|
If you are an experienced user of C or C++ (or Fortran or Objective-C)
|
|
compilers, your suggestions
|
|
for improvement of GCC are welcome in any case.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Bug Lists"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC137"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC136" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC136"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC138" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC138"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC138" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC138"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 8.2 Where to Report Bugs </H2>
|
|
<!--docid::SEC137::-->
|
|
Send bug reports for the GNU Compiler Collection to
|
|
<SAMP>`gcc-bugs@gcc.gnu.org'</SAMP>. In accordance with the GNU-wide
|
|
convention, in which bug reports for tool "foo" are sent
|
|
to <SAMP>`bug-foo@gnu.org'</SAMP>, the address <SAMP>`bug-gcc@gnu.org'</SAMP>
|
|
may also be used; it will forward to the address given above.
|
|
<P>
|
|
|
|
Please read <SAMP>`<URL:http://www.gnu.org/software/gcc/bugs.html>'</SAMP> for
|
|
bug reporting instructions before you post a bug report.
|
|
</P><P>
|
|
|
|
Often people think of posting bug reports to the newsgroup instead of
|
|
mailing them. This appears to work, but it has one problem which can be
|
|
crucial: a newsgroup posting does not contain a mail path back to the
|
|
sender. Thus, if maintainers need more information, they may be unable
|
|
to reach you. For this reason, you should always send bug reports by
|
|
mail to the proper mailing list.
|
|
</P><P>
|
|
|
|
As a last resort, send bug reports on paper to:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=example><pre>GNU Compiler Bugs
|
|
Free Software Foundation
|
|
59 Temple Place - Suite 330
|
|
Boston, MA 02111-1307, USA
|
|
</pre></td></tr></table></P><P>
|
|
|
|
<A NAME="Bug Reporting"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC138"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC137" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC137"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC139" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC139"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC139" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC139"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 8.3 How to Report Bugs </H2>
|
|
<!--docid::SEC138::-->
|
|
<P>
|
|
|
|
You may find additional and/or more up-to-date instructions at
|
|
<SAMP>`<URL:http://www.gnu.org/software/gcc/bugs.html>'</SAMP>.
|
|
</P><P>
|
|
|
|
The fundamental principle of reporting bugs usefully is this:
|
|
<STRONG>report all the facts</STRONG>. If you are not sure whether to state a
|
|
fact or leave it out, state it!
|
|
</P><P>
|
|
|
|
Often people omit facts because they think they know what causes the
|
|
problem and they conclude that some details don't matter. Thus, you might
|
|
assume that the name of the variable you use in an example does not matter.
|
|
Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a
|
|
stray memory reference which happens to fetch from the location where that
|
|
name is stored in memory; perhaps, if the name were different, the contents
|
|
of that location would fool the compiler into doing the right thing despite
|
|
the bug. Play it safe and give a specific, complete example. That is the
|
|
easiest thing for you to do, and the most helpful.
|
|
</P><P>
|
|
|
|
Keep in mind that the purpose of a bug report is to enable someone to
|
|
fix the bug if it is not known. It isn't very important what happens if
|
|
the bug is already known. Therefore, always write your bug reports on
|
|
the assumption that the bug is not known.
|
|
</P><P>
|
|
|
|
Sometimes people give a few sketchy facts and ask, "Does this ring a
|
|
bell?" This cannot help us fix a bug, so it is basically useless. We
|
|
respond by asking for enough details to enable us to investigate.
|
|
You might as well expedite matters by sending them to begin with.
|
|
</P><P>
|
|
|
|
Try to make your bug report self-contained. If we have to ask you for
|
|
more information, it is best if you include all the previous information
|
|
in your response, as well as the information that was missing.
|
|
</P><P>
|
|
|
|
Please report each bug in a separate message. This makes it easier for
|
|
us to track which bugs have been fixed and to forward your bugs reports
|
|
to the appropriate maintainer.
|
|
</P><P>
|
|
|
|
To enable someone to investigate the bug, you should include all these
|
|
things:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
The version of GCC. You can get this by running it with the
|
|
<SAMP>`-v'</SAMP> option.
|
|
<P>
|
|
|
|
Without this, we won't know whether there is any point in looking for
|
|
the bug in the current version of GCC.
|
|
</P><P>
|
|
|
|
<LI>
|
|
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 (<TT>`cc1'</TT>), send the
|
|
preprocessor output generated by adding <SAMP>`-save-temps'</SAMP> to the
|
|
compilation command (see section <A HREF="gcc_2.html#SEC9" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC9">2.7 Options for Debugging Your Program or GCC</A>). When you do this, use
|
|
the same <SAMP>`-I'</SAMP>, <SAMP>`-D'</SAMP> or <SAMP>`-U'</SAMP> options that you used in
|
|
actual compilation. Then send the <VAR>input</VAR>.i or <VAR>input</VAR>.ii files
|
|
generated.
|
|
<P>
|
|
|
|
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
|
|
might depend on the details of how this is done.
|
|
</P><P>
|
|
|
|
Without a real example one can compile, all anyone can do about your bug
|
|
report is wish you luck. It would be futile to try to guess how to
|
|
provoke the bug. For example, bugs in register allocation and reloading
|
|
frequently depend on every little detail of the function they happen in.
|
|
</P><P>
|
|
|
|
Even if the input file that fails comes from a GNU program, you should
|
|
still send the complete test case. Don't ask the GCC maintainers to
|
|
do the extra work of obtaining the program in question--they are all
|
|
overworked as it is. Also, the problem may depend on what is in the
|
|
header files on your system; it is unreliable for the GCC maintainers
|
|
to try the problem with the header files available to them. By sending
|
|
CPP output, you can eliminate this source of uncertainty and save us
|
|
a certain percentage of wild goose chases.
|
|
</P><P>
|
|
|
|
<LI>
|
|
The command arguments you gave GCC to compile that example
|
|
and observe the bug. For example, did you use <SAMP>`-O'</SAMP>? To guarantee
|
|
you won't omit something important, list all the options.
|
|
<P>
|
|
|
|
If we were to try to guess the arguments, we would probably guess wrong
|
|
and then we would not encounter the bug.
|
|
</P><P>
|
|
|
|
<LI>
|
|
The type of machine you are using, and the operating system name and
|
|
version number.
|
|
<P>
|
|
|
|
<LI>
|
|
The operands you gave to the <CODE>configure</CODE> command when you installed
|
|
the compiler.
|
|
<P>
|
|
|
|
<LI>
|
|
A complete list of any modifications you have made to the compiler
|
|
source. (We don't promise to investigate the bug unless it happens in
|
|
an unmodified compiler. But if you've made modifications and don't tell
|
|
us, then you are sending us on a wild goose chase.)
|
|
<P>
|
|
|
|
Be precise about these changes. A description in English is not
|
|
enough--send a context diff for them.
|
|
</P><P>
|
|
|
|
Adding files of your own (such as a machine description for a machine we
|
|
don't support) is a modification of the compiler source.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Details of any other deviations from the standard procedure for installing
|
|
GCC.
|
|
<P>
|
|
|
|
<LI>
|
|
A description of what behavior you observe that you believe is
|
|
incorrect. For example, "The compiler gets a fatal signal," or,
|
|
"The assembler instruction at line 208 in the output is incorrect."
|
|
<P>
|
|
|
|
Of course, if the bug is that the compiler gets a fatal signal, then one
|
|
can't miss it. But if the bug is incorrect output, the maintainer might
|
|
not notice unless it is glaringly wrong. None of us has time to study
|
|
all the assembler code from a 50-line C program just on the chance that
|
|
one instruction might be wrong. We need <EM>you</EM> to do this part!
|
|
</P><P>
|
|
|
|
Even if the problem you experience is a fatal signal, you should still
|
|
say so explicitly. Suppose something strange is going on, such as, your
|
|
copy of the compiler is out of synch, or you have encountered a bug in
|
|
the C library on your system. (This has happened!) Your copy might
|
|
crash and the copy here would not. If you <I>said</I> to expect a crash,
|
|
then when the compiler here fails to crash, we would know that the bug
|
|
was not happening. If you don't say to expect a crash, then we would
|
|
not know whether the bug was happening. We would not be able to draw
|
|
any conclusion from our observations.
|
|
</P><P>
|
|
|
|
If the problem is a diagnostic when compiling GCC with some other
|
|
compiler, say whether it is a warning or an error.
|
|
</P><P>
|
|
|
|
Often the observed symptom is incorrect output when your program is run.
|
|
Sad to say, this is not enough information unless the program is short
|
|
and simple. None of us has time to study a large program to figure out
|
|
how it would work if compiled correctly, much less which line of it was
|
|
compiled wrong. So you will have to do that. Tell us which source line
|
|
it is, and what incorrect result happens when that line is executed. A
|
|
person who understands the program can find this as easily as finding a
|
|
bug in the program itself.
|
|
</P><P>
|
|
|
|
<LI>
|
|
If you send examples of assembler code output from GCC,
|
|
please use <SAMP>`-g'</SAMP> when you make them. The debugging information
|
|
includes source line numbers which are essential for correlating the
|
|
output with the input.
|
|
<P>
|
|
|
|
<LI>
|
|
If you wish to mention something in the GCC source, refer to it by
|
|
context, not by line number.
|
|
<P>
|
|
|
|
The line numbers in the development sources don't match those in your
|
|
sources. Your line numbers would convey no useful information to the
|
|
maintainers.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Additional information from a debugger might enable someone to find a
|
|
problem on a machine which he does not have available. However, you
|
|
need to think when you collect this information if you want it to have
|
|
any chance of being useful.
|
|
<P>
|
|
|
|
<A NAME="IDX413"></A>
|
|
For example, many people send just a backtrace, but that is never
|
|
useful by itself. A simple backtrace with arguments conveys little
|
|
about GCC because the compiler is largely data-driven; the same
|
|
functions are called over and over for different RTL insns, doing
|
|
different things depending on the details of the insn.
|
|
</P><P>
|
|
|
|
Most of the arguments listed in the backtrace are useless because they
|
|
are pointers to RTL list structure. The numeric values of the
|
|
pointers, which the debugger prints in the backtrace, have no
|
|
significance whatever; all that matters is the contents of the objects
|
|
they point to (and most of the contents are other such pointers).
|
|
</P><P>
|
|
|
|
In addition, most compiler passes consist of one or more loops that
|
|
scan the RTL insn sequence. The most vital piece of information about
|
|
such a loop--which insn it has reached--is usually in a local variable,
|
|
not in an argument.
|
|
</P><P>
|
|
|
|
<A NAME="IDX414"></A>
|
|
What you need to provide in addition to a backtrace are the values of
|
|
the local variables for several stack frames up. When a local
|
|
variable or an argument is an RTX, first print its value and then use
|
|
the GDB command <CODE>pr</CODE> to print the RTL expression that it points
|
|
to. (If GDB doesn't run on your machine, use your debugger to call
|
|
the function <CODE>debug_rtx</CODE> with the RTX as an argument.) In
|
|
general, whenever a variable is a pointer, its value is no use
|
|
without the data it points to.
|
|
</UL>
|
|
<P>
|
|
|
|
Here are some things that are not necessary:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
A description of the envelope of the bug.
|
|
<P>
|
|
|
|
Often people who encounter a bug spend a lot of time investigating
|
|
which changes to the input file will make the bug go away and which
|
|
changes will not affect it.
|
|
</P><P>
|
|
|
|
This is often time consuming and not very useful, because the way we
|
|
will find the bug is by running a single example under the debugger with
|
|
breakpoints, not by pure deduction from a series of examples. You might
|
|
as well save your time for something else.
|
|
</P><P>
|
|
|
|
Of course, if you can find a simpler example to report <EM>instead</EM> of
|
|
the original one, that is a convenience. Errors in the output will be
|
|
easier to spot, running under the debugger will take less time, etc.
|
|
Most GCC bugs involve just one function, so the most straightforward
|
|
way to simplify an example is to delete all the function definitions
|
|
except the one where the bug occurs. Those earlier in the file may be
|
|
replaced by external declarations if the crucial function depends on
|
|
them. (Exception: inline functions may affect compilation of functions
|
|
defined later in the file.)
|
|
</P><P>
|
|
|
|
However, simplification is not vital; if you don't want to do this,
|
|
report the bug anyway and send the entire test case you used.
|
|
</P><P>
|
|
|
|
<LI>
|
|
In particular, some people insert conditionals <SAMP>`#ifdef BUG'</SAMP> around
|
|
a statement which, if removed, makes the bug not happen. These are just
|
|
clutter; we won't pay any attention to them anyway. Besides, you should
|
|
send us cpp output, and that can't have conditionals.
|
|
<P>
|
|
|
|
<LI>
|
|
A patch for the bug.
|
|
<P>
|
|
|
|
A patch for the bug is useful if it is a good one. But don't omit the
|
|
necessary information, such as the test case, on the assumption that a
|
|
patch is all we need. We might see problems with your patch and decide
|
|
to fix the problem another way, or we might not understand it at all.
|
|
</P><P>
|
|
|
|
Sometimes with a program as complicated as GCC it is very hard to
|
|
construct an example that will make the program follow a certain path
|
|
through the code. If you don't send the example, we won't be able to
|
|
construct one, so we won't be able to verify that the bug is fixed.
|
|
</P><P>
|
|
|
|
And if we can't understand what bug you are trying to fix, or why your
|
|
patch should be an improvement, we won't install it. A test case will
|
|
help us to understand.
|
|
</P><P>
|
|
|
|
See section <A HREF="gcc_8.html#SEC139" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC139">8.4 Sending Patches for GCC</A>, for guidelines on how to make it easy for us to
|
|
understand and install your patches.
|
|
</P><P>
|
|
|
|
<LI>
|
|
A guess about what the bug is or what it depends on.
|
|
<P>
|
|
|
|
Such guesses are usually wrong. Even I can't guess right about such
|
|
things without first using the debugger to find the facts.
|
|
</P><P>
|
|
|
|
<LI>
|
|
A core dump file.
|
|
<P>
|
|
|
|
We have no way of examining a core dump for your type of machine
|
|
unless we have an identical system--and if we do have one,
|
|
we should be able to reproduce the crash ourselves.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Sending Patches"></A>
|
|
<HR SIZE="6">
|
|
<A NAME="SEC139"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC138" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC138"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 8.4 Sending Patches for GCC </H2>
|
|
<!--docid::SEC139::-->
|
|
<P>
|
|
|
|
If you would like to write bug fixes or improvements for the GNU C
|
|
compiler, that is very helpful. Send suggested fixes to the patches
|
|
mailing list, <CODE>gcc-patches@gcc.gnu.org</CODE>.
|
|
</P><P>
|
|
|
|
Please follow these guidelines so we can study your patches efficiently.
|
|
If you don't follow these guidelines, your information might still be
|
|
useful, but using it will take extra work. Maintaining GNU C is a lot
|
|
of work in the best of circumstances, and we can't keep up unless you do
|
|
your best to help.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
Send an explanation with your changes of what problem they fix or what
|
|
improvement they bring about. For a bug fix, just include a copy of the
|
|
bug report, and explain why the change fixes the bug.
|
|
<P>
|
|
|
|
(Referring to a bug report is not as good as including it, because then
|
|
we will have to look it up, and we have probably already deleted it if
|
|
we've already fixed the bug.)
|
|
</P><P>
|
|
|
|
<LI>
|
|
Always include a proper bug report for the problem you think you have
|
|
fixed. We need to convince ourselves that the change is right before
|
|
installing it. Even if it is right, we might have trouble judging it if
|
|
we don't have a way to reproduce the problem.
|
|
<P>
|
|
|
|
<LI>
|
|
Include all the comments that are appropriate to help people reading the
|
|
source in the future understand why this change was needed.
|
|
<P>
|
|
|
|
<LI>
|
|
Don't mix together changes made for different reasons.
|
|
Send them <EM>individually</EM>.
|
|
<P>
|
|
|
|
If you make two changes for separate reasons, then we might not want to
|
|
install them both. We might want to install just one. If you send them
|
|
all jumbled together in a single set of diffs, we have to do extra work
|
|
to disentangle them--to figure out which parts of the change serve
|
|
which purpose. If we don't have time for this, we might have to ignore
|
|
your changes entirely.
|
|
</P><P>
|
|
|
|
If you send each change as soon as you have written it, with its own
|
|
explanation, then the two changes never get tangled up, and we can
|
|
consider each one properly without any extra work to disentangle them.
|
|
</P><P>
|
|
|
|
Ideally, each change you send should be impossible to subdivide into
|
|
parts that we might want to consider separately, because each of its
|
|
parts gets its motivation from the other parts.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Send each change as soon as that change is finished. Sometimes people
|
|
think they are helping us by accumulating many changes to send them all
|
|
together. As explained above, this is absolutely the worst thing you
|
|
could do.
|
|
<P>
|
|
|
|
Since you should send each change separately, you might as well send it
|
|
right away. That gives us the option of installing it immediately if it
|
|
is important.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Use <SAMP>`diff -c'</SAMP> to make your diffs. Diffs without context are hard
|
|
for us to install reliably. More than that, they make it hard for us to
|
|
study the diffs to decide whether we want to install them. Unidiff
|
|
format is better than contextless diffs, but not as easy to read as
|
|
<SAMP>`-c'</SAMP> format.
|
|
<P>
|
|
|
|
If you have GNU diff, use <SAMP>`diff -cp'</SAMP>, which shows the name of the
|
|
function that each change occurs in.
|
|
</P><P>
|
|
|
|
<LI>
|
|
Write the change log entries for your changes. We get lots of changes,
|
|
and we don't have time to do all the change log writing ourselves.
|
|
<P>
|
|
|
|
Read the <TT>`ChangeLog'</TT> file to see what sorts of information to put
|
|
in, and to learn the style that we use. The purpose of the change log
|
|
is to show people where to find what was changed. So you need to be
|
|
specific about what functions you changed; in large functions, it's
|
|
often helpful to indicate where within the function the change was.
|
|
</P><P>
|
|
|
|
On the other hand, once you have shown people where to find the change,
|
|
you need not explain its purpose. Thus, if you add a new function, all
|
|
you need to say about it is that it is new. If you feel that the
|
|
purpose needs explaining, it probably does--but the explanation will be
|
|
much more useful if you put it in comments in the code.
|
|
</P><P>
|
|
|
|
If you would like your name to appear in the header line for who made
|
|
the change, send us the header line.
|
|
</P><P>
|
|
|
|
<LI>
|
|
When you write the fix, keep in mind that we can't install a change that
|
|
would break other systems.
|
|
<P>
|
|
|
|
People often suggest fixing a problem by changing machine-independent
|
|
files such as <TT>`toplev.c'</TT> to do something special that a particular
|
|
system needs. Sometimes it is totally obvious that such changes would
|
|
break GCC for almost all users. We can't possibly make a change like
|
|
that. At best it might tell us how to write another patch that would
|
|
solve the problem acceptably.
|
|
</P><P>
|
|
|
|
Sometimes people send fixes that <EM>might</EM> be an improvement in
|
|
general--but it is hard to be sure of this. It's hard to install
|
|
such changes because we have to study them very carefully. Of course,
|
|
a good explanation of the reasoning by which you concluded the change
|
|
was correct can help convince us.
|
|
</P><P>
|
|
|
|
The safest changes are changes to the configuration files for a
|
|
particular machine. These are safe because they can't create new bugs
|
|
on other machines.
|
|
</P><P>
|
|
|
|
Please help us keep up with the workload by designing the patch in a
|
|
form that is good to install.
|
|
</UL>
|
|
<P>
|
|
|
|
<A NAME="Service"></A>
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_8.html#SEC135" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_8.html#SEC135"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_9.html#SEC140" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_9.html#SEC140"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc.html#SEC_Top" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_toc.html#SEC_Contents" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_24.html#SEC261" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_24.html#SEC261">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gcc_abt.html#SEC_About" tppabs="http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
This document was generated
|
|
by <I>GCC Administrator</I> on <I>March, 17 2001</I>
|
|
using <A HREF="tppmsgs/msgs0.htm#1" tppabs="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|