File: README.Bugs.m4

package info (click to toggle)
gcc-4.8 4.8.4-1
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 587,180 kB
  • ctags: 425
  • sloc: makefile: 65,711; sh: 1,248; perl: 165; awk: 23; cpp: 14
file content (333 lines) | stat: -rw-r--r-- 12,231 bytes parent folder | download | duplicates (51)
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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
Reporting Bugs in the GNU Compiler Collection for DIST
========================================================

Before reporting a bug, please
------------------------------

- Check that the behaviour really is a bug. Have a look into some
  ANSI standards document.

- Check the list of well known bugs: http://gcc.gnu.org/bugs.html#known

- Try to reproduce the bug with a current GCC development snapshot. You
  usually can get a recent development snapshot from the gcc-snapshot
ifelse(DIST,`Debian',`dnl
  package in the unstable (or experimental) distribution.

  See: http://packages.debian.org/gcc-snapshot
', DIST, `Ubuntu',`dnl
  package in the current development distribution.

  See: http://archive.ubuntu.com/ubuntu/pool/universe/g/gcc-snapshot/
')dnl

- Try to find out if the bug is a regression (an older GCC version does
  not show the bug).

- Check if the bug is already reported in the bug tracking systems.

ifelse(DIST,`Debian',`dnl
    Debian:   http://bugs.debian.org/debian-gcc@lists.debian.org
', DIST, `Ubuntu',`dnl
    Ubuntu:   https://bugs.launchpad.net/~ubuntu-toolchain/+packagebugs
    Debian:   http://bugs.debian.org/debian-gcc@lists.debian.org
')dnl
    Upstream: http://gcc.gnu.org/bugzilla/


Where to report a bug
---------------------

ifelse(DIST,`Debian',`dnl
Please report bugs found in the packaging of GCC to the Debian bug tracking
system. See http://www.debian.org/Bugs/ for instructions (or use the
reportbug script).
', DIST, `Ubuntu',`dnl
Please report bugs found in the packaging of GCC to Launchpad. See below
how issues should be reported.
')dnl

DIST's current policy is to closely follow the upstream development and
only apply a minimal set of patches (which are summarized in the README.Debian
document).

ifelse(DIST,`Debian',`dnl
If you think you have found an upstream bug, you did check the section
above ("Before reporting a bug") and are able to provide a complete bug
report (see below "How to report a bug"), then you may help the Debian
GCC package maintainers, if you report the bug upstream and then submit
a bug report to the Debian BTS and tell us the upstream report number.
This way you are able to follow the upstream bug handling as well. If in
doubt, report the bug to the Debian BTS (but read "How to report a bug"
below).
', DIST, `Ubuntu',`dnl
If you think you have found an upstream bug, you did check the section
above ("Before reporting a bug") and are able to provide a complete bug
report (see below "How to report a bug"), then you may help the Ubuntu
GCC package maintainers, if you report the bug upstream and then submit
a bug report to Launchpad and tell us the upstream report number.
This way you are able to follow the upstream bug handling as well. If in
doubt, report the bug to Launchpad (but read "How to report a bug" below).

Report the issue to https://bugs.launchpad.net/ubuntu/+source/SRCNAME.
')dnl


How to report a bug
-------------------

There are complete instructions in the gcc info manual (found in the
gcc-doc package), section Bugs.

The manual can be read using `M-x info' in Emacs, or if the GNU info
program is installed on your system by `info --node "(gcc)Bugs"'. Or see
the file BUGS included with the gcc source code.

Online bug reporting instructions can be found at

	http://gcc.gnu.org/bugs.html

[Some paragraphs taken from the above URL]

The main purpose of a bug report is to enable us to fix the bug. The
most important prerequisite for this is that the report must be
complete and self-contained, which we explain in detail below.

Before you report a bug, please check the list of well-known bugs and,
if possible in any way, try a current development snapshot.

Summarized bug reporting instructions
-------------------------------------

What we need

Please include in your bug report all of the following items, the
first three of which can be obtained from the output of gcc -v:

    * the exact version of GCC;
    * the system type;
    * the options given when GCC was configured/built;
    * the complete command line that triggers the bug;
    * the compiler output (error messages, warnings, etc.); and
    * the preprocessed file (*.i*) that triggers the bug, generated by
      adding -save-temps to the complete compilation command, or, in
      the case of a bug report for the GNAT front end, a complete set
      of source files (see below).

What we do not want

    * A source file that #includes header files that are left out
      of the bug report (see above)
    * That source file and a collection of header files.
    * An attached archive (tar, zip, shar, whatever) containing all
      (or some :-) of the above.
    * A code snippet that won't cause the compiler to produce the
      exact output mentioned in the bug report (e.g., a snippet with
      just a few lines around the one that apparently triggers the
      bug, with some pieces replaced with ellipses or comments for
      extra obfuscation :-)
    * The location (URL) of the package that failed to build (we won't
      download it, anyway, since you've already given us what we need
      to duplicate the bug, haven't you? :-)
    * An error that occurs only some of the times a certain file is
      compiled, such that retrying a sufficient number of times
      results in a successful compilation; this is a symptom of a
      hardware problem, not of a compiler bug (sorry)
    * E-mail messages that complement previous, incomplete bug
      reports. Post a new, self-contained, full bug report instead, if
      possible as a follow-up to the original bug report
    * Assembly files (*.s) produced by the compiler, or any binary files,
      such as object files, executables, core files, or precompiled
      header files
    * Duplicate bug reports, or reports of bugs already fixed in the
      development tree, especially those that have already been
      reported as fixed last week :-)
    * Bugs in the assembler, the linker or the C library. These are
      separate projects, with separate mailing lists and different bug
      reporting procedures
    * Bugs in releases or snapshots of GCC not issued by the GNU
      Project. Report them to whoever provided you with the release
    * Questions about the correctness or the expected behavior of
      certain constructs that are not GCC extensions. Ask them in
      forums dedicated to the discussion of the programming language


Known Bugs and Non-Bugs
-----------------------

[Please see /usr/share/doc/gcc/FAQ or http://gcc.gnu.org/faq.html first]


C++ exceptions don't work with C libraries
------------------------------------------

[Taken from the closed bug report #22769] C++ exceptions don't work
with C libraries, if the C code wasn't designed to be thrown through.
A solution could be to translate all C libraries with -fexceptions.
Mostly trying to throw an exception in a callback function (qsort,
Tcl command callbacks, etc ...). Example:

    #include <stdio.h>
    #include <tcl.h>

    class A {};

    static
    int SortCondition(void const*, void const*)
    {
        printf("throwing 'sortcondition' exception\n");
        throw A();
    }

    int main(int argc, char *argv[])
    {
        int list[2];

        try {
            SortCondition(NULL,NULL);
        } catch (A) {
            printf("caught test-sortcondition exception\n");
        }
        try {
            qsort(&list, sizeof(list)/sizeof(list[0]),sizeof(list[0]),
                 &SortCondition);
        } catch (A) {
            printf("caught real-sortcondition exception\n");
        }
        return 0;
}

Andrew Macleod <amacleod@cygnus.com> responded:

When compiled with the table driven exception handling, exception can only
be thrown through functions which have been compiled with the table driven EH.
If a function isn't compiled that way, then we do not have the frame
unwinding information required to restore the registers when unwinding.

I believe the setjmp/longjmp mechanism will throw through things like this, 
but its produces much messier code.  (-fsjlj-exceptions)

The C compiler does support exceptions, you just have to turn them on
with -fexceptions.

Your main options are to:
  a) Don't use callbacks, or at least don't throw through them.
  b) Get the source and compile the library with -fexceptions (You have to
     explicitly turn on exceptions in the C compiler)
  c) always use -fsjlj-exceptions (boo, bad choice :-)


g++: "undefined reference" to static const array in class
---------------------------------------------------------

The following code compiles under GNU C++ 2.7.2 with correct results,
but produces the same linker error with GNU C++ 2.95.2.
Alexandre Oliva <oliva@lsd.ic.unicamp.br> responded:

All of them are correct.  A static data member *must* be defined
outside the class body even if it is initialized within the class
body, but no diagnostic is required if the definition is missing.  It
turns out that some releases do emit references to the missing symbol,
while others optimize it away.

#include <iostream>

class Test
{
  public:
    Test(const char *q);
  protected:
    static const unsigned char  Jam_signature[4]   = "JAM";
};

Test::Test(const char *q)
{
  if (memcmp(q, Jam_signature, sizeof(Jam_signature)) != 0)
  cerr << "Hello world!\n";
}

int main(void)
{
  Test::Test("JAM");
  return 0;
}

g++: g++ causes passing non const ptr to ptr to a func with const arg
     to cause an error (not a bug)
---------------------------------------------------------------------

Example:

#include <stdio.h>
void test(const char **b){
        printf ("%s\n",*b);
}
int main(void){
        char *test1="aoeu";
        test(&test1);
}

make const
g++     const.cc   -o const
const.cc: In function `int main()':
const.cc:7: passing `char **' as argument 1 of `test(const char **)' adds cv-quals without intervening `const'
make: *** [const] Error 1

Answer from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>:

> ok... maybe I missed something.. I haven't really kept up with the latest in
> C++ news.  But I've never heard anything even remotly close to passing a non
> const var into a const arg being an error before.

Thanks for your bug report. This is a not a bug in the compiler, but
in your code. The standard, in 4.4/4, puts it that way

# A conversion can add cv-qualifiers at levels other than the first in
# multi-level pointers, subject to the following rules:
# Two pointer types T1 and T2 are similar if there exists a type T and
# integer n > 0 such that:
#   T1 is cv(1,0) pointer to cv(1,1) pointer to ... cv(1,n-1)
#   pointer to cv(1,n) T
# and
#   T2 is cv(2,0) pointer to cv(2,1) pointer to ... cv(2,n-1)
#   pointer to cv(2,n) T
# where each cv(i,j) is const, volatile, const volatile, or
# nothing. The n-tuple of cv-qualifiers after the first in a pointer
# type, e.g., cv(1,1) , cv(1,2) , ... , cv(1,n) in the pointer type
# T1, is called the cv-qualification signature of the pointer type. An
# expression of type T1 can be converted to type T2 if and only if the
# following conditions are satisfied:
#  - the pointer types are similar.
#  - for every j > 0, if const is in cv(1,j) then const is in cv(2,j) ,
#    and similarly for volatile.
#  - if the cv(1,j) and cv(2,j) are different, then const is in every
#    cv(2,k) for 0 < k < j.

It is the last rule that your code violates. The standard gives then
the following example as a rationale:

# [Note: if a program could assign a pointer of type T** to a pointer
# of type const T** (that is, if line //1 below was allowed), a
# program could inadvertently modify a const object (as it is done on
# line //2). For example,
# int main() { 
#   const char c = 'c'; 
#   char* pc; 
#   const char** pcc = &pc; //1: not allowed 
#   *pcc = &c; 
#   *pc = 'C'; //2: modifies a const object 
# }
# - end note]

If you question this line of reasoning, please discuss it in one of
the public C++ fora first, eg. comp.lang.c++.moderated, or
comp.std.c++.


cpp removes blank lines
-----------------------

With the new cpp, you need to add -traditional to the "cpp -P" args, else 
blank lines get removed.

[EDIT ME: scan Debian bug reports and write some nice summaries ...]