1 | <html> |
---|
2 | |
---|
3 | <head> |
---|
4 | <title>GCC Bugs</title> |
---|
5 | </head> |
---|
6 | |
---|
7 | <body> |
---|
8 | <h1>GCC Bugs</h1> |
---|
9 | |
---|
10 | <p>The latest version of this document is always available at |
---|
11 | <a href="http://www.gnu.org/software/gcc/bugs.html">http://www.gnu.org/software/gcc/bugs.html</a>.</p> |
---|
12 | |
---|
13 | <hr /> |
---|
14 | |
---|
15 | <h2>Table of Contents</h2> |
---|
16 | <ul> |
---|
17 | <li><a href="#report">Reporting Bugs</a> |
---|
18 | <ul> |
---|
19 | <li><a href="#need">What we need</a></li> |
---|
20 | <li><a href="#dontwant">What we DON'T want</a></li> |
---|
21 | <li><a href="#where">Where to post it</a></li> |
---|
22 | <li><a href="#detailed">Detailed bug reporting instructions</a></li> |
---|
23 | <li><a href="#gnat">Detailed bug reporting instructions for GNAT</a></li> |
---|
24 | </ul> |
---|
25 | </li> |
---|
26 | <li><a href="#manage">Managing Bugs (GNATS and the test-suite)</a></li> |
---|
27 | <li><a href="#known">Frequently Reported Bugs in GCC</a> |
---|
28 | <ul> |
---|
29 | <li><a href="#general">General</a></li> |
---|
30 | <li><a href="#fortran">Fortran</a></li> |
---|
31 | <li><a href="#c">C</a></li> |
---|
32 | <li><a href="#cplusplus">C++</a> |
---|
33 | <ul> |
---|
34 | <li><a href="#updating">Common problems updating from G++ 2.95 to |
---|
35 | G++ 3.0</a></li> |
---|
36 | <li><a href="#nonbugs">Non-bugs</a></li> |
---|
37 | <li><a href="#missing">Missing features</a></li> |
---|
38 | <li><a href="#parsing">Parse errors for "simple" code</a></li> |
---|
39 | <li><a href="#-O3">Optimization at <code>-O3</code> takes a |
---|
40 | very long time</a></li> |
---|
41 | </ul> |
---|
42 | </li> |
---|
43 | </ul> |
---|
44 | </li> |
---|
45 | </ul> |
---|
46 | |
---|
47 | <hr /> |
---|
48 | |
---|
49 | <h1><a name="report">Reporting Bugs</a></h1> |
---|
50 | |
---|
51 | <p>Our preferred way of receiving bugs is via the |
---|
52 | <a href="gnats.html">GCC GNATS bug reporting system</a>.</p> |
---|
53 | |
---|
54 | <p>Before you report a bug, please check the |
---|
55 | <a href="#known">list of well-known bugs</a> and, <strong>if possible |
---|
56 | in any way, try a current development snapshot</strong>. |
---|
57 | If you want to report a bug with versions of GCC before 3.1 we strongly |
---|
58 | recommend upgrading to the current release first.</p> |
---|
59 | |
---|
60 | <p>Before reporting that GCC compiles your code incorrectly, please |
---|
61 | compile it with <code>gcc -Wall</code> and see whether this shows |
---|
62 | anything wrong with your code that could be the cause instead of a bug |
---|
63 | in GCC.</p> |
---|
64 | |
---|
65 | <h2>Summarized bug reporting instructions</h2> |
---|
66 | |
---|
67 | <p>After this summary, you'll find detailed bug reporting |
---|
68 | instructions, that explain how to obtain some of the information |
---|
69 | requested in this summary.</p> |
---|
70 | |
---|
71 | <h3><a name="need">What we need</a></h3> |
---|
72 | |
---|
73 | Please include in your bug report all of the following items, the first |
---|
74 | three of which can be obtained from the output of <code>gcc -v</code>: |
---|
75 | |
---|
76 | <ul> |
---|
77 | <li>the exact version of GCC;</li> |
---|
78 | <li>the system type;</li> |
---|
79 | <li>the options given when GCC was configured/built;</li> |
---|
80 | <li>the complete command line that triggers the bug;</li> |
---|
81 | <li>the compiler output (error messages, warnings, etc.); and</li> |
---|
82 | <li>the <em>preprocessed</em> file (<code>*.i*</code>) that triggers the |
---|
83 | bug, generated by adding <code>-save-temps</code> to the complete |
---|
84 | compilation command, or, in the case of a bug report for the GNAT front end, |
---|
85 | a complete set of source files (see below).</li> |
---|
86 | </ul> |
---|
87 | |
---|
88 | <h3><a name="dontwant">What we do <strong>not</strong> want</a></h3> |
---|
89 | |
---|
90 | <ul> |
---|
91 | <li>A source file that <code>#include</code>s header files that are left |
---|
92 | out of the bug report (see above)</li> |
---|
93 | |
---|
94 | <li>That source file and a collection of header files.</li> |
---|
95 | |
---|
96 | <li>An attached archive (tar, zip, shar, whatever) containing all |
---|
97 | (or some :-) of the above.</li> |
---|
98 | |
---|
99 | <li>A code snippet that won't cause the compiler to produce the |
---|
100 | exact output mentioned in the bug report (e.g., a snippet with just |
---|
101 | a few lines around the one that <b>apparently</b> triggers the bug, |
---|
102 | with some pieces replaced with ellipses or comments for extra |
---|
103 | obfuscation :-)</li> |
---|
104 | |
---|
105 | <li>The location (URL) of the package that failed to build (we won't |
---|
106 | download it, anyway, since you've already given us what we need to |
---|
107 | duplicate the bug, haven't you? :-)</li> |
---|
108 | |
---|
109 | <li>An error that occurs only some of the times a certain file is |
---|
110 | compiled, such that retrying a sufficient number of times results in |
---|
111 | a successful compilation; this is a symptom of a hardware problem, |
---|
112 | not of a compiler bug (sorry)</li> |
---|
113 | |
---|
114 | <li>E-mail messages that complement previous, incomplete bug |
---|
115 | reports. Post a new, self-contained, full bug report instead, if |
---|
116 | possible as a follow-up to the original bug report</li> |
---|
117 | |
---|
118 | <li>Assembly files (<code>*.s</code>) produced by the compiler, or any |
---|
119 | binary files, such as object files, executables or core files</li> |
---|
120 | |
---|
121 | <li>Duplicate bug reports, or reports of bugs already fixed in the |
---|
122 | development tree, especially those that have already been reported |
---|
123 | as fixed last week :-)</li> |
---|
124 | |
---|
125 | <li>Bugs in the assembler, the linker or the C library. These are |
---|
126 | separate projects, with separate mailing lists and different bug |
---|
127 | reporting procedures</li> |
---|
128 | |
---|
129 | <li>Bugs in releases or snapshots of GCC not issued by the GNU |
---|
130 | Project. Report them to whoever provided you with the release</li> |
---|
131 | |
---|
132 | <li>Questions about the correctness or the expected behavior of |
---|
133 | certain constructs that are not GCC extensions. Ask them in forums |
---|
134 | dedicated to the discussion of the programming language</li> |
---|
135 | </ul> |
---|
136 | |
---|
137 | <h3><a name="where">Where to post it</a></h3> |
---|
138 | |
---|
139 | <p>Please submit your bug report directly to the |
---|
140 | <a href="gnats.html">GCC GNATS bug database</a>. |
---|
141 | Only if this is not possible, mail all information to |
---|
142 | <a href="mailto:bug-gcc@gnu.org">bug-gcc@gnu.org</a> or |
---|
143 | <a href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a>.</p> |
---|
144 | |
---|
145 | <p>The GCC lists have message size limits (200 kbytes) and bug reports |
---|
146 | over those limits will currently be bounced. If your bug is larger |
---|
147 | than that, please post it using the <a href="gnats.html">GCC GNATS bug |
---|
148 | database</a>.</p> |
---|
149 | |
---|
150 | <h2><a name="detailed">Detailed bug reporting instructions</a></h2> |
---|
151 | |
---|
152 | <p>Please refer to the <a href="#gnat">next section</a> when reporting |
---|
153 | bugs in GNAT, the Ada compiler.</p> |
---|
154 | |
---|
155 | <p>In general, all the information we need can be obtained by |
---|
156 | collecting the command line below, as well as its output and the |
---|
157 | preprocessed file it generates.</p> |
---|
158 | |
---|
159 | <blockquote><code>gcc -v -save-temps <i>all-your-options |
---|
160 | source-file</i></code></blockquote> |
---|
161 | |
---|
162 | <p>Typically the preprocessed file (extension <code>.i</code> for C or |
---|
163 | <code>.ii</code> for C++) will be large, so please compress the |
---|
164 | resulting file with one of the popular compression programs such as |
---|
165 | bzip2, gzip, zip or compress (in |
---|
166 | decreasing order of preference). Use maximum compression |
---|
167 | (<code>-9</code>) if available. Please include the compressed |
---|
168 | preprocessor output in your bug report, even if the source code is |
---|
169 | freely available elsewhere; it makes the job of our volunteer testers |
---|
170 | much easier.</p> |
---|
171 | |
---|
172 | <p>The <b>only</b> excuses to not send us the preprocessed sources are |
---|
173 | (i) if you've found a bug in the preprocessor, or (ii) if you've |
---|
174 | reduced the testcase to a small file that doesn't include any |
---|
175 | other file. If you can't post the preprocessed sources because |
---|
176 | they're proprietary code, then try to create a small file that |
---|
177 | triggers the same problem.</p> |
---|
178 | |
---|
179 | <p>Since we're supposed to be able to re-create the assembly output |
---|
180 | (extension <code>.s</code>), you usually should not include |
---|
181 | it in the bug report, although you may want to post parts of it to |
---|
182 | point out assembly code you consider to be wrong.</p> |
---|
183 | |
---|
184 | <p>Whether to use MIME attachments or <code>uuencode</code> is up to |
---|
185 | you. In any case, make sure the compiler command line, version and |
---|
186 | error output are in plain text, so that we don't have to decode the |
---|
187 | bug report in order to tell who should take care of it. A meaningful |
---|
188 | subject indicating language and platform also helps.</p> |
---|
189 | |
---|
190 | <p>Please avoid posting an archive (.tar, .shar or .zip); we generally |
---|
191 | need just a single file to reproduce the bug (the .i/.ii preprocessed |
---|
192 | file), and, by storing it in an archive, you're just making our |
---|
193 | volunteers' jobs harder. Only when your bug report requires multiple |
---|
194 | source files to be reproduced should you use an archive. In any case, |
---|
195 | make sure the compiler version, error message, etc, are included in |
---|
196 | the body of your bug report as plain text, even if needlessly |
---|
197 | duplicated as part of an archive.</p> |
---|
198 | |
---|
199 | <p>If you fail to supply enough information for a bug report to be |
---|
200 | reproduced, someone will probably ask you to post additional |
---|
201 | information (or just ignore your bug report, if they're in a bad day, |
---|
202 | so try to get it right on the first posting :-). In this case, please |
---|
203 | post the additional information to the bug reporting mailing list, not |
---|
204 | just to the person who requested it, unless explicitly told so. If |
---|
205 | possible, please include in this follow-up all the information you had |
---|
206 | supplied in the incomplete bug report (including the preprocessor |
---|
207 | output), so that the new bug report is self-contained.</p> |
---|
208 | |
---|
209 | <h2><a name="gnat">Detailed bug reporting instructions for GNAT</a></h2> |
---|
210 | |
---|
211 | <p>See the <a href="#detailed">previous section</a> for bug reporting |
---|
212 | instructions for GCC language implementations other than Ada.</p> |
---|
213 | |
---|
214 | <p>Bug reports have to contain at least the following information in |
---|
215 | order to be useful:</p> |
---|
216 | |
---|
217 | <ul> |
---|
218 | <li>the exact version of GCC, as shown by "<code>gcc -v</code>";</li> |
---|
219 | <li>the system type;</li> |
---|
220 | <li>the options when GCC was configured/built;</li> |
---|
221 | <li>the exact command line passed to the <code>gcc</code> program |
---|
222 | triggering the bug |
---|
223 | (not just the flags passed to <code>gnatmake</code>, but |
---|
224 | <code>gnatmake</code> prints the parameters it passed to <code>gcc</code>)</li> |
---|
225 | <li>a collection of source files for reproducing the bug, |
---|
226 | preferably a minimal set (see below);</li> |
---|
227 | <li>a description of the expected behavior;</li> |
---|
228 | <li>a description of actual behavior.</li> |
---|
229 | </ul> |
---|
230 | |
---|
231 | <p>If your code depends on additional source files (usually package |
---|
232 | specifications), submit the source code for these compilation units in |
---|
233 | a single file that is acceptable input to <code>gnatchop</code>, |
---|
234 | i.e. contains no non-Ada text. If the compilation terminated |
---|
235 | normally, you can usually obtain a list of dependencies using the |
---|
236 | "<code>gnatls -d <i>main_unit</i></code>" command, where |
---|
237 | <code><i>main_unit</i></code> is the file name of the main compilation |
---|
238 | unit (which is also passed to <code>gcc</code>).</p> |
---|
239 | |
---|
240 | <p>If you report a bug which causes the compiler to print a bug box, |
---|
241 | include that bug box in your report, and do not forget to send all the |
---|
242 | source files listed after the bug box along with your report.</p> |
---|
243 | |
---|
244 | <p>If you use <code>gnatprep</code>, be sure to send in preprocessed |
---|
245 | sources (unless you have to report a bug in <code>gnatprep</code>).</p> |
---|
246 | |
---|
247 | <p>When you have checked that your report meets these criteria, please |
---|
248 | submit it accoding to our <a href="#where">generic instructions</a>. |
---|
249 | (If you use a mailing list for reporting, please include an |
---|
250 | "<code>[Ada]</code>" tag in the subject.)</p> |
---|
251 | |
---|
252 | <h1><a name="manage">Managing Bugs (GNATS and the test-suite)</a></h1> |
---|
253 | |
---|
254 | <p>This section contains information mostly intended for GCC |
---|
255 | contributors.</p> |
---|
256 | |
---|
257 | <p>If you find a bug, but you are not fixing it (yet):</p> |
---|
258 | <ol> |
---|
259 | <li>Create a (minimal) test-case.</li> |
---|
260 | <li>Add the test-case to our test-suite, marking it as XFAIL unless |
---|
261 | the bug is a regression.</li> |
---|
262 | <li>Add a bug report referencing the test-case to GNATS.</li> |
---|
263 | </ol> |
---|
264 | |
---|
265 | <p>If you fix a bug for which there is already a GNATS entry:</p> |
---|
266 | <ol> |
---|
267 | <li>Remove the XFAIL on the test-case.</li> |
---|
268 | <li>Close the bug report in GNATS.</li> |
---|
269 | </ol> |
---|
270 | |
---|
271 | <p>If you find a bug, and you are fixing it right then:</p> |
---|
272 | <ol> |
---|
273 | <li>Create a (minimal) test-case.</li> |
---|
274 | <li>Add the test-case to our test-suite, marking it as PASS.</li> |
---|
275 | <li>Check in your fixes.</li> |
---|
276 | </ol> |
---|
277 | |
---|
278 | <hr /> |
---|
279 | |
---|
280 | <h1><a name="known">Frequently Reported Bugs in GCC</a></h1> |
---|
281 | |
---|
282 | <h2><a name="fortran">Fortran</a></h2> |
---|
283 | |
---|
284 | <p>Fortran bugs are documented in the G77 manual rather than |
---|
285 | explicitly listed here. Please see |
---|
286 | <a href="http://gcc.gnu.org/onlinedocs/g77/Trouble.html">Known Causes of |
---|
287 | Trouble with GNU Fortran</a> in the G77 manual.</p> |
---|
288 | |
---|
289 | <hr /> |
---|
290 | |
---|
291 | <h2><a name="c">C</a></h2> |
---|
292 | |
---|
293 | <p>The following are not bugs in the C compiler, but are reported |
---|
294 | often enough to warrant a mention here.</p> |
---|
295 | |
---|
296 | <dl> |
---|
297 | <dt>Cannot initialize a static variable with <code>stdin</code>.</dt> |
---|
298 | <dd><p>This has nothing to do with GCC, but people ask us about it a |
---|
299 | lot. Code like this:</p> |
---|
300 | |
---|
301 | <blockquote><pre> |
---|
302 | #include <stdio.h> |
---|
303 | |
---|
304 | FILE *yyin = stdin; |
---|
305 | </pre></blockquote> |
---|
306 | |
---|
307 | <p>will not compile with GNU libc (GNU/Linux libc6), because |
---|
308 | <code>stdin</code> is not a constant. This was done deliberately, to make |
---|
309 | it easier to maintain binary compatibility when the type <code>FILE</code> |
---|
310 | needs to be changed. It is surprising for people used to traditional Unix |
---|
311 | C libraries, but it is permitted by the C standard.</p> |
---|
312 | |
---|
313 | <p>This construct commonly occurs in code generated by old versions of |
---|
314 | lex or yacc. We suggest you try regenerating the parser with a |
---|
315 | current version of flex or bison, respectively. In your own code, the |
---|
316 | appropriate fix is to move the initialization to the beginning of |
---|
317 | main.</p> |
---|
318 | |
---|
319 | <p>There is a common misconception that the GCC developers are |
---|
320 | responsible for GNU libc. These are in fact two entirely separate |
---|
321 | projects; please check the |
---|
322 | <a href="http://www.gnu.org/software/glibc/">GNU libc web pages</a> |
---|
323 | for details. |
---|
324 | </p></dd> |
---|
325 | |
---|
326 | <dt>Cannot use preprocessor directive in macro arguments.</dt> |
---|
327 | <dd><p>Let me guess... you wrote code that looks something like this:</p> |
---|
328 | <blockquote><pre> |
---|
329 | memcpy(dest, src, |
---|
330 | #ifdef PLATFORM1 |
---|
331 | 12 |
---|
332 | #else |
---|
333 | 24 |
---|
334 | #endif |
---|
335 | ); |
---|
336 | </pre></blockquote> |
---|
337 | <p>and you got a whole pile of error messages:</p> |
---|
338 | <blockquote><code> |
---|
339 | |
---|
340 | test.c:11: warning: preprocessing directive not recognized within |
---|
341 | macro arg<br /> |
---|
342 | test.c:11: warning: preprocessing directive not recognized within |
---|
343 | macro arg<br /> |
---|
344 | test.c:11: warning: preprocessing directive not recognized within |
---|
345 | macro arg<br /> |
---|
346 | test.c: In function `foo':<br /> |
---|
347 | test.c:6: undefined or invalid # directive<br /> |
---|
348 | test.c:8: undefined or invalid # directive<br /> |
---|
349 | test.c:9: parse error before `24'<br /> |
---|
350 | test.c:10: undefined or invalid # directive<br /> |
---|
351 | test.c:11: parse error before `#'<br /> |
---|
352 | </code></blockquote> |
---|
353 | |
---|
354 | <p><strong>Update:</strong> As of GCC 3.2 this kind of construct is |
---|
355 | always accepted and CPP will probably do what you expect, but see the |
---|
356 | manual for detailed semantics.</p> |
---|
357 | |
---|
358 | <p>However, versions of GCC prior to 3.2 did not allow you to put |
---|
359 | <code>#ifdef</code> (or any other directive) inside the arguments of a |
---|
360 | macro. Your C library's <code><string.h></code> happens to |
---|
361 | define <code>memcpy</code> as a macro - this is perfectly legitimate. |
---|
362 | The code therefore would not compile.</p> |
---|
363 | |
---|
364 | <p>This kind of code is not portable. It is "undefined behavior" |
---|
365 | according to the C standard; that means different compilers will do |
---|
366 | different things with it. It is always possible to rewrite code which |
---|
367 | uses conditionals inside macros so that it doesn't. You could write |
---|
368 | the above example</p> |
---|
369 | <blockquote><pre> |
---|
370 | #ifdef PLATFORM1 |
---|
371 | memcpy(dest, src, 12); |
---|
372 | #else |
---|
373 | memcpy(dest, src, 24); |
---|
374 | #endif |
---|
375 | </pre></blockquote> |
---|
376 | <p>This is a bit more typing, but I personally think it's better style |
---|
377 | in addition to being more portable.</p> |
---|
378 | |
---|
379 | <p>In recent versions of glibc, <code>printf</code> is among the |
---|
380 | functions which are implemented as macros.</p></dd> |
---|
381 | </dl> |
---|
382 | |
---|
383 | <hr /> |
---|
384 | |
---|
385 | <h2><a name="cplusplus">C++</a></h2> |
---|
386 | |
---|
387 | <p>This is the list of bugs (and non-bugs) in g++ (aka GNU C++) that |
---|
388 | are reported very often, but not yet fixed. While it is certainly |
---|
389 | better to fix bugs instead of documenting them, this document might |
---|
390 | save people the effort of writing a bug report when the bug is already |
---|
391 | well-known. <a href="#report">How to report bugs</a> tells you how to |
---|
392 | report a bug.</p> |
---|
393 | |
---|
394 | <p>There are many reasons why reported bugs don't get fixed. It might |
---|
395 | be difficult to fix, or fixing it might break compatibility. Often, |
---|
396 | reports get a low priority when there is a simple work-around. In |
---|
397 | particular, bugs caused by invalid C++ code have a simple work-around, |
---|
398 | <em>fix the code</em>. Now that there is an agreed ISO/ANSI standard |
---|
399 | for C++, the compiler has a definitive document to adhere to. Earlier |
---|
400 | versions might have accepted source code that is <em>no longer</em> |
---|
401 | C++. This means that code which might have `worked' in a previous |
---|
402 | version, is now rejected. You should update your code to be C++.</p> |
---|
403 | |
---|
404 | <p>You should try to use the latest stable release of the GNU C++ |
---|
405 | compiler.</p> |
---|
406 | |
---|
407 | <h3><a name="updating">Common problems updating from G++ 2.95 to G++ |
---|
408 | 3.0</a></h3> |
---|
409 | |
---|
410 | <p>G++ 3.0 conforms much closer to the ISO C++ standard (available at |
---|
411 | <a href="http://www.ncits.org/cplusplus.htm">http://www.ncits.org/cplusplus.htm</a>).</p> |
---|
412 | |
---|
413 | <p>We have also implemented some of the core and library defect reports |
---|
414 | (available at |
---|
415 | <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html">http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html</a> |
---|
416 | & |
---|
417 | <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html"> |
---|
418 | http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html</a> |
---|
419 | respectively).</p> |
---|
420 | |
---|
421 | <ul> |
---|
422 | |
---|
423 | <li>The ABI has changed. This means that both class layout and name |
---|
424 | mangling is different. You <em>must</em> recompile all c++ libraries (if |
---|
425 | you don't you will get link errors).</li> |
---|
426 | |
---|
427 | <li>The standard library is much more conformant, and uses the |
---|
428 | <code>std::</code> namespace.</li> |
---|
429 | |
---|
430 | <li><code>std::</code> is now a real namespace, not an alias for |
---|
431 | <code>::</code>.</li> |
---|
432 | |
---|
433 | <li>The standard header files for the c library don't end with |
---|
434 | <code>.h</code>, but begin with <code>c</code> (i.e. |
---|
435 | <code><cstdlib></code> rather than <code><stdlib.h></code>). |
---|
436 | The <code>.h</code> names are still available, but are deprecated.</li> |
---|
437 | |
---|
438 | <li><code><strstream></code> is deprecated, use |
---|
439 | <code><sstream></code> instead.</li> |
---|
440 | |
---|
441 | <li><code>streambuf::seekoff</code> & |
---|
442 | <code>streambuf::seekpos</code> are private, instead use |
---|
443 | <code>streambuf::pubseekoff</code> & |
---|
444 | <code>streambuf::pubseekpos</code> respectively.</li> |
---|
445 | |
---|
446 | <li>If <code>std::operator << (std::ostream &, long long)</code> |
---|
447 | doesn't exist, you need to recompile libstdc++ with |
---|
448 | <code>--enable-long-long</code>.</li> |
---|
449 | |
---|
450 | </ul> |
---|
451 | |
---|
452 | This means you may get lots of errors about things like |
---|
453 | <code>strcmp</code> not being found. You've most likely forgotton to |
---|
454 | tell the compiler to look in the <code>std::</code> namespace. There are |
---|
455 | several ways to do this, |
---|
456 | |
---|
457 | <ul> |
---|
458 | |
---|
459 | <li>Say, <code>std::strcmp</code> at the call. This is the most explicit |
---|
460 | way of saying what you mean.</li> |
---|
461 | |
---|
462 | <li>Say, <code>using std::strcmp;</code> somewhere before the call. You |
---|
463 | will need to do this for each function or type you wish to use from the |
---|
464 | standard library.</li> |
---|
465 | |
---|
466 | <li>Say, <code>using namespace std;</code> somewhere before the call. |
---|
467 | This is the quick-but-dirty fix. This brings the <em>whole</em> of the |
---|
468 | <code>std::</code> namespace into scope. <em>Never</em> do this in a |
---|
469 | header file, as you will be forcing users of your header file to do the |
---|
470 | same.</li> |
---|
471 | |
---|
472 | </ul> |
---|
473 | |
---|
474 | <h3><a name="abi">ABI bugs</a></h3> |
---|
475 | |
---|
476 | <p>3.0 had a new ABI, which affected class layout, function mangling and |
---|
477 | calling conventions. We had intended it to be complete, unfortunately |
---|
478 | some issues came to light, too late to fix in the 3.0 series. |
---|
479 | The ABI should not change in dot releases, so we addressed most issues |
---|
480 | in GCC 3.1. |
---|
481 | </p> |
---|
482 | |
---|
483 | <dl> |
---|
484 | |
---|
485 | <dt>Covariant return types</dt> |
---|
486 | |
---|
487 | <dd>We do not implement non-trivial covariant returns. We also generate |
---|
488 | incorrect virtual function tables for trivial covariance. Although |
---|
489 | trivial covariance will work, it is incompatible with the ABI. GNATS PR |
---|
490 | 3706 tracks this problem.</dd> |
---|
491 | |
---|
492 | </dl> |
---|
493 | |
---|
494 | <h3><a name="nonbugs">Non-bugs</a></h3> |
---|
495 | |
---|
496 | <p>Here are some features that have been reported as bugs, but are |
---|
497 | not.</p> |
---|
498 | |
---|
499 | <dl> |
---|
500 | |
---|
501 | <dt>Nested classes can access private types of the containing |
---|
502 | class.</dt> |
---|
503 | <dd><p>G++ now implements type access control on member types. Defect |
---|
504 | report 45 clarifies that nested classes are members of the class they |
---|
505 | are nested in, and so are granted access to private members of that |
---|
506 | class.</p></dd> |
---|
507 | |
---|
508 | <dt>Classes in exception specifiers must be complete types.</dt> |
---|
509 | <dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or |
---|
510 | pointer to incomplete (other than <code><i>cv</i> void *</code>) in |
---|
511 | an exception specification.</p></dd> |
---|
512 | |
---|
513 | <dt>G++ emits two copies of constructors and destructors.</dt> |
---|
514 | |
---|
515 | <dd><p>In general there are <em>three</em> types of constructors (and |
---|
516 | destructors).</p> |
---|
517 | <ol> |
---|
518 | <li>The complete object constructor/destructor.</li> |
---|
519 | <li>The base object constructor/destructor.</li> |
---|
520 | <li>The allocating destructor/deallocating destructor.</li> |
---|
521 | </ol> |
---|
522 | <p>The first two are different, when virtual base classes are involved. |
---|
523 | In some cases we can do better, and this is logged in GNATS.</p></dd> |
---|
524 | |
---|
525 | <dt>Exceptions don't work in multithreaded applications.</dt> |
---|
526 | |
---|
527 | <dd><p>You need to rebuild g++ and libstdc++ with |
---|
528 | <code>--enable-threads</code>. Remember, c++ exceptions are not like |
---|
529 | hardware interrupts. You cannot throw an exception in one thread and |
---|
530 | catch it in another. You cannot throw an exception from a signal |
---|
531 | handler, and catch it in the main thread.</p></dd> |
---|
532 | |
---|
533 | <dt>Global destructors are not run in the correct order.</dt> |
---|
534 | |
---|
535 | <dd><p>Global destructors should be run in the reverse order of their |
---|
536 | constructors <em>completing</em>. In most cases this is the same as |
---|
537 | the reverse order of constructors <em>starting</em>, but sometimes it |
---|
538 | is different, and that is important. You need to compile and link your |
---|
539 | programs with <code>--use-cxa-atexit</code>. We have not turned this |
---|
540 | switch on by default, as it requires a <code>cxa</code> aware runtime |
---|
541 | library (<code>libc</code>, <code>glibc</code>, or |
---|
542 | equivalent).</p></dd> |
---|
543 | |
---|
544 | <dt>Problems with floating point computations.</dt> |
---|
545 | <dd><p>In a number of cases, GCC appears to perform floating point |
---|
546 | computations incorrectly. For example, the program</p> |
---|
547 | <blockquote><code> |
---|
548 | #include <iostream><br /> |
---|
549 | <br /> |
---|
550 | int main() {<br /> |
---|
551 | <br /> |
---|
552 | double min = 0.0;<br /> |
---|
553 | double max = 0.5;<br /> |
---|
554 | double width = 0.01;<br /> |
---|
555 | std::cout << (int)(((max - min) / width) - 1) << |
---|
556 | std::endl;<br /> |
---|
557 | <br /> |
---|
558 | }<br /> |
---|
559 | </code></blockquote> |
---|
560 | <p>might print 50 on some systems and optimization levels, and 51 on |
---|
561 | others.</p> |
---|
562 | |
---|
563 | <p>The is the result of <em>rounding</em>: The computer cannot |
---|
564 | represent all real numbers exactly, so it has to use |
---|
565 | approximations. When computing with approximation, the computer needs |
---|
566 | to round to the nearest representable number.</p> |
---|
567 | |
---|
568 | <p>This is not a bug in the compiler, but an inherent limitation of |
---|
569 | the float and double types. Please study |
---|
570 | <a href="http://www.validlab.com/goldberg/paper.ps">this paper</a> |
---|
571 | for more information.</p></dd> |
---|
572 | |
---|
573 | <dt>Templates, scoping, and digraphs.</dt> |
---|
574 | |
---|
575 | <dd><p>If you have a class in global namespace, say named |
---|
576 | <code>X</code>, and want to give it as a template argument to some |
---|
577 | other class, say <code>std::vector</code>, then this here fails with a |
---|
578 | parser error: <code>std::vector<::X></code>. |
---|
579 | </p> |
---|
580 | |
---|
581 | <p> |
---|
582 | The reason is that the standard mandates that the sequence |
---|
583 | <code><:</code> is treated as if it were the token |
---|
584 | <code>[</code>, and the parser then reports a parse error before the |
---|
585 | character <code>:</code> (by which it means the second |
---|
586 | colon). There are several such combinations of characters, and |
---|
587 | they are called <em>digraphs</em>. |
---|
588 | </p> |
---|
589 | |
---|
590 | <p> |
---|
591 | The simplest way to avoid this is to write <code>std::vector< |
---|
592 | ::X></code>, i.e. place a space between the opening angle bracket |
---|
593 | and the scope operator. |
---|
594 | </p></dd> |
---|
595 | |
---|
596 | |
---|
597 | </dl> |
---|
598 | |
---|
599 | <h3><a name="missing">Missing features</a></h3> |
---|
600 | <p>We know some things are missing from G++.</p> |
---|
601 | |
---|
602 | <dl> |
---|
603 | |
---|
604 | <dt>The <code>export</code> keyword is not implemented.</dt> |
---|
605 | <dd><p>Most C++ compilers (G++ included) do not yet implement |
---|
606 | <code>export</code>, which is necessary for separate compilation of |
---|
607 | template declarations and definitions. Without <code>export</code>, a |
---|
608 | template definition must be in scope to be used. The obvious |
---|
609 | workaround is simply to place all definitions in the header |
---|
610 | itself. Alternatively, the compilation unit containing template |
---|
611 | definitions may be included from the header.</p></dd> |
---|
612 | |
---|
613 | <dt>Two stage lookup in templates is not implemented.</dt> |
---|
614 | <dd><p>[14.6] specifies how names are looked up inside a template. G++ |
---|
615 | does not do this correctly, but for most templates this will not be |
---|
616 | noticeable.</p></dd> |
---|
617 | |
---|
618 | </dl> |
---|
619 | |
---|
620 | <h3><a name="parsing">Parse errors for "simple" code</a></h3> |
---|
621 | |
---|
622 | Up to and including GCC 3.0, the compiler will give "parse error" for |
---|
623 | seemingly simple code, such as |
---|
624 | |
---|
625 | <pre> |
---|
626 | struct A{ |
---|
627 | A(); |
---|
628 | A(int); |
---|
629 | void func(); |
---|
630 | }; |
---|
631 | |
---|
632 | struct B{ |
---|
633 | B(A); |
---|
634 | B(A,A); |
---|
635 | void func(); |
---|
636 | }; |
---|
637 | |
---|
638 | void foo(){ |
---|
639 | B b(A(),A(1)); //Variable b, initialized with two temporaries |
---|
640 | B(A(2)).func(); //B temporary, initialized with A temporary |
---|
641 | } |
---|
642 | </pre> |
---|
643 | The problem is that GCC starts to parse the declaration of |
---|
644 | <code>b</code> as a function <code>b</code> returning <code>B</code>, |
---|
645 | taking a function returning <code>A</code> as an argument. When it |
---|
646 | sees the 1, it is too late. The work-around in these cases is to add |
---|
647 | additional parentheses around the expressions that are mistaken as |
---|
648 | declarations: |
---|
649 | <pre> |
---|
650 | (B(A(2))).func(); |
---|
651 | </pre> |
---|
652 | Sometimes, even that is not enough; to show the compiler that this |
---|
653 | should be really an expression, a comma operator with a dummy argument |
---|
654 | can be used: |
---|
655 | <pre> |
---|
656 | B b((0,A()),A(1)); |
---|
657 | </pre> |
---|
658 | <p> |
---|
659 | Another example is the parse error for the <code>return</code> |
---|
660 | statement in</p> |
---|
661 | <pre> |
---|
662 | struct A{}; |
---|
663 | |
---|
664 | struct B{ |
---|
665 | A a; |
---|
666 | A f1(bool); |
---|
667 | }; |
---|
668 | |
---|
669 | A B::f1(bool b) |
---|
670 | { |
---|
671 | if (b) |
---|
672 | return (A()); |
---|
673 | return a; |
---|
674 | } |
---|
675 | </pre> |
---|
676 | <p>The problem is that the compiler interprets <code>A()</code> as a |
---|
677 | function (taking no arguments, returning <code>A</code>), and |
---|
678 | <code>(A()</code>) as a cast - with a missing expression, hence the |
---|
679 | parse error. The work-around is to omit the parentheses:</p> |
---|
680 | <pre> |
---|
681 | if (b) |
---|
682 | return A(); |
---|
683 | </pre> |
---|
684 | <p>This problem occurs in a number of variants; in <code>throw</code> |
---|
685 | statements, people also frequently put the object in parentheses. The |
---|
686 | exact error also somewhat varies with the compiler version. The |
---|
687 | work-arounds proposed do not change the semantics of the program at |
---|
688 | all; they make them perhaps less readable.</p> |
---|
689 | |
---|
690 | <h3><a name="-O3">Optimization at <code>-O3</code> takes a |
---|
691 | very long time</a></h3> |
---|
692 | <p>At <code>-O3</code>, all functions are candidates for inlining. The |
---|
693 | heuristic used has some deficiencies which show up when allowed such |
---|
694 | freedom. This is g++ specific, as it has an earlier inliner than |
---|
695 | gcc.</p> |
---|
696 | |
---|
697 | </body> |
---|
698 | </html> |
---|