aboutsummaryrefslogtreecommitdiff
path: root/gcc/doc/bugreport.texi
blob: a64d5de469db8f91661fe8e9e0f1793084610d34 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
@c Copyright (C) 1988-2016 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.
@end menu

@node Bug Criteria
@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
@section How and Where to Report Bugs
@cindex compiler bugs, reporting

Bugs should be reported to the bug database at @value{BUGURL}.