Subversion Repositories openrisc_2011-10-31

@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,

@c 1999, 2000, 2001, 2003, 2004, 2007 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 bug database at @value{BUGURL}.