1
Reporting Bugs in the GNU Compiler Collection for DIST
2
========================================================
4
Before reporting a bug, please
5
------------------------------
7
- Check that the behaviour really is a bug. Have a look into some
8
ANSI standards document.
10
- Check the list of well known bugs: http://gcc.gnu.org/bugs.html#known
12
- Try to reproduce the bug with a current GCC development snapshot. You
13
usually can get a recent development snapshot from the gcc-snapshot
14
ifelse(DIST,`Debian',`dnl
15
package in the unstable (or experimental) distribution.
17
See: http://packages.debian.org/gcc-snapshot
18
', DIST, `Ubuntu',`dnl
19
package in the current development distribution.
21
See: http://archive.ubuntu.com/ubuntu/pool/universe/g/gcc-snapshot/
24
- Try to find out if the bug is a regression (an older GCC version does
27
- Check if the bug is already reported in the bug tracking systems.
29
ifelse(DIST,`Debian',`dnl
30
Debian: http://bugs.debian.org/debian-gcc@lists.debian.org
31
', DIST, `Ubuntu',`dnl
32
Ubuntu: https://bugs.launchpad.net/~ubuntu-toolchain/+packagebugs
33
Debian: http://bugs.debian.org/debian-gcc@lists.debian.org
35
Upstream: http://gcc.gnu.org/bugzilla/
41
ifelse(DIST,`Debian',`dnl
42
Please report bugs found in the packaging of GCC to the Debian bug tracking
43
system. See http://www.debian.org/Bugs/ for instructions (or use the
45
', DIST, `Ubuntu',`dnl
46
Please report bugs found in the packaging of GCC to Launchpad. See below
47
how issues should be reported.
50
DIST's current policy is to closely follow the upstream development and
51
only apply a minimal set of patches (which are summarized in the README.Debian
54
ifelse(DIST,`Debian',`dnl
55
If you think you have found an upstream bug, you did check the section
56
above ("Before reporting a bug") and are able to provide a complete bug
57
report (see below "How to report a bug"), then you may help the Debian
58
GCC package maintainers, if you report the bug upstream and then submit
59
a bug report to the Debian BTS and tell us the upstream report number.
60
This way you are able to follow the upstream bug handling as well. If in
61
doubt, report the bug to the Debian BTS (but read "How to report a bug"
63
', DIST, `Ubuntu',`dnl
64
If you think you have found an upstream bug, you did check the section
65
above ("Before reporting a bug") and are able to provide a complete bug
66
report (see below "How to report a bug"), then you may help the Ubuntu
67
GCC package maintainers, if you report the bug upstream and then submit
68
a bug report to Launchpad and tell us the upstream report number.
69
This way you are able to follow the upstream bug handling as well. If in
70
doubt, report the bug to Launchpad (but read "How to report a bug" below).
72
Report the issue to https://bugs.launchpad.net/ubuntu/+source/SRCNAME.
79
There are complete instructions in the gcc info manual (found in the
80
gcc-doc package), section Bugs.
82
The manual can be read using `M-x info' in Emacs, or if the GNU info
83
program is installed on your system by `info --node "(gcc)Bugs"'. Or see
84
the file BUGS included with the gcc source code.
86
Online bug reporting instructions can be found at
88
http://gcc.gnu.org/bugs.html
90
[Some paragraphs taken from the above URL]
92
The main purpose of a bug report is to enable us to fix the bug. The
93
most important prerequisite for this is that the report must be
94
complete and self-contained, which we explain in detail below.
96
Before you report a bug, please check the list of well-known bugs and,
97
if possible in any way, try a current development snapshot.
99
Summarized bug reporting instructions
100
-------------------------------------
104
Please include in your bug report all of the following items, the
105
first three of which can be obtained from the output of gcc -v:
107
* the exact version of GCC;
109
* the options given when GCC was configured/built;
110
* the complete command line that triggers the bug;
111
* the compiler output (error messages, warnings, etc.); and
112
* the preprocessed file (*.i*) that triggers the bug, generated by
113
adding -save-temps to the complete compilation command, or, in
114
the case of a bug report for the GNAT front end, a complete set
115
of source files (see below).
119
* A source file that #includes header files that are left out
120
of the bug report (see above)
121
* That source file and a collection of header files.
122
* An attached archive (tar, zip, shar, whatever) containing all
123
(or some :-) of the above.
124
* A code snippet that won't cause the compiler to produce the
125
exact output mentioned in the bug report (e.g., a snippet with
126
just a few lines around the one that apparently triggers the
127
bug, with some pieces replaced with ellipses or comments for
128
extra obfuscation :-)
129
* The location (URL) of the package that failed to build (we won't
130
download it, anyway, since you've already given us what we need
131
to duplicate the bug, haven't you? :-)
132
* An error that occurs only some of the times a certain file is
133
compiled, such that retrying a sufficient number of times
134
results in a successful compilation; this is a symptom of a
135
hardware problem, not of a compiler bug (sorry)
136
* E-mail messages that complement previous, incomplete bug
137
reports. Post a new, self-contained, full bug report instead, if
138
possible as a follow-up to the original bug report
139
* Assembly files (*.s) produced by the compiler, or any binary files,
140
such as object files, executables, core files, or precompiled
142
* Duplicate bug reports, or reports of bugs already fixed in the
143
development tree, especially those that have already been
144
reported as fixed last week :-)
145
* Bugs in the assembler, the linker or the C library. These are
146
separate projects, with separate mailing lists and different bug
148
* Bugs in releases or snapshots of GCC not issued by the GNU
149
Project. Report them to whoever provided you with the release
150
* Questions about the correctness or the expected behavior of
151
certain constructs that are not GCC extensions. Ask them in
152
forums dedicated to the discussion of the programming language
155
Known Bugs and Non-Bugs
156
-----------------------
158
[Please see /usr/share/doc/gcc/FAQ or http://gcc.gnu.org/faq.html first]
161
C++ exceptions don't work with C libraries
162
------------------------------------------
164
[Taken from the closed bug report #22769] C++ exceptions don't work
165
with C libraries, if the C code wasn't designed to be thrown through.
166
A solution could be to translate all C libraries with -fexceptions.
167
Mostly trying to throw an exception in a callback function (qsort,
168
Tcl command callbacks, etc ...). Example:
176
int SortCondition(void const*, void const*)
178
printf("throwing 'sortcondition' exception\n");
182
int main(int argc, char *argv[])
187
SortCondition(NULL,NULL);
189
printf("caught test-sortcondition exception\n");
192
qsort(&list, sizeof(list)/sizeof(list[0]),sizeof(list[0]),
195
printf("caught real-sortcondition exception\n");
200
Andrew Macleod <amacleod@cygnus.com> responded:
202
When compiled with the table driven exception handling, exception can only
203
be thrown through functions which have been compiled with the table driven EH.
204
If a function isn't compiled that way, then we do not have the frame
205
unwinding information required to restore the registers when unwinding.
207
I believe the setjmp/longjmp mechanism will throw through things like this,
208
but its produces much messier code. (-fsjlj-exceptions)
210
The C compiler does support exceptions, you just have to turn them on
213
Your main options are to:
214
a) Don't use callbacks, or at least don't throw through them.
215
b) Get the source and compile the library with -fexceptions (You have to
216
explicitly turn on exceptions in the C compiler)
217
c) always use -fsjlj-exceptions (boo, bad choice :-)
220
g++: "undefined reference" to static const array in class
221
---------------------------------------------------------
223
The following code compiles under GNU C++ 2.7.2 with correct results,
224
but produces the same linker error with GNU C++ 2.95.2.
225
Alexandre Oliva <oliva@lsd.ic.unicamp.br> responded:
227
All of them are correct. A static data member *must* be defined
228
outside the class body even if it is initialized within the class
229
body, but no diagnostic is required if the definition is missing. It
230
turns out that some releases do emit references to the missing symbol,
231
while others optimize it away.
240
static const unsigned char Jam_signature[4] = "JAM";
243
Test::Test(const char *q)
245
if (memcmp(q, Jam_signature, sizeof(Jam_signature)) != 0)
246
cerr << "Hello world!\n";
255
g++: g++ causes passing non const ptr to ptr to a func with const arg
256
to cause an error (not a bug)
257
---------------------------------------------------------------------
262
void test(const char **b){
271
g++ const.cc -o const
272
const.cc: In function `int main()':
273
const.cc:7: passing `char **' as argument 1 of `test(const char **)' adds cv-quals without intervening `const'
274
make: *** [const] Error 1
276
Answer from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>:
278
> ok... maybe I missed something.. I haven't really kept up with the latest in
279
> C++ news. But I've never heard anything even remotly close to passing a non
280
> const var into a const arg being an error before.
282
Thanks for your bug report. This is a not a bug in the compiler, but
283
in your code. The standard, in 4.4/4, puts it that way
285
# A conversion can add cv-qualifiers at levels other than the first in
286
# multi-level pointers, subject to the following rules:
287
# Two pointer types T1 and T2 are similar if there exists a type T and
288
# integer n > 0 such that:
289
# T1 is cv(1,0) pointer to cv(1,1) pointer to ... cv(1,n-1)
290
# pointer to cv(1,n) T
292
# T2 is cv(2,0) pointer to cv(2,1) pointer to ... cv(2,n-1)
293
# pointer to cv(2,n) T
294
# where each cv(i,j) is const, volatile, const volatile, or
295
# nothing. The n-tuple of cv-qualifiers after the first in a pointer
296
# type, e.g., cv(1,1) , cv(1,2) , ... , cv(1,n) in the pointer type
297
# T1, is called the cv-qualification signature of the pointer type. An
298
# expression of type T1 can be converted to type T2 if and only if the
299
# following conditions are satisfied:
300
# - the pointer types are similar.
301
# - for every j > 0, if const is in cv(1,j) then const is in cv(2,j) ,
302
# and similarly for volatile.
303
# - if the cv(1,j) and cv(2,j) are different, then const is in every
304
# cv(2,k) for 0 < k < j.
306
It is the last rule that your code violates. The standard gives then
307
the following example as a rationale:
309
# [Note: if a program could assign a pointer of type T** to a pointer
310
# of type const T** (that is, if line //1 below was allowed), a
311
# program could inadvertently modify a const object (as it is done on
312
# line //2). For example,
314
# const char c = 'c';
316
# const char** pcc = &pc; //1: not allowed
318
# *pc = 'C'; //2: modifies a const object
322
If you question this line of reasoning, please discuss it in one of
323
the public C++ fora first, eg. comp.lang.c++.moderated, or
327
cpp removes blank lines
328
-----------------------
330
With the new cpp, you need to add -traditional to the "cpp -P" args, else
331
blank lines get removed.
333
[EDIT ME: scan Debian bug reports and write some nice summaries ...]
added
removed
.svn/pristine/9b/9b652c49ad3b086728db7d344c3b277673ff5c55.svn-base
