| 1 | |
| 2 | GCC Bugs |
| 3 | |
| 4 | The latest version of this document is always available at |
| 5 | [1]http://gcc.gnu.org/bugs.html. |
| 6 | _________________________________________________________________ |
| 7 | |
| 8 | Table of Contents |
| 9 | |
| 10 | * [2]Reporting Bugs |
| 11 | + [3]What we need |
| 12 | + [4]What we DON'T want |
| 13 | + [5]Where to post it |
| 14 | + [6]Detailed bug reporting instructions |
| 15 | + [7]Detailed bug reporting instructions for GNAT |
| 16 | + [8]Detailed bug reporting instructions when using a |
| 17 | precompiled header |
| 18 | * [9]Frequently Reported Bugs in GCC |
| 19 | + [10]C++ |
| 20 | o [11]Missing features |
| 21 | o [12]Bugs fixed in the 3.4 series |
| 22 | + [13]Fortran |
| 23 | * [14]Non-bugs |
| 24 | + [15]General |
| 25 | + [16]C |
| 26 | + [17]C++ |
| 27 | o [18]Common problems when upgrading the compiler |
| 28 | _________________________________________________________________ |
| 29 | |
| 30 | Reporting Bugs |
| 31 | |
| 32 | The main purpose of a bug report is to enable us to fix the bug. The |
| 33 | most important prerequisite for this is that the report must be |
| 34 | complete and self-contained. |
| 35 | |
| 36 | Before you report a bug, please check the [19]list of well-known bugs |
| 37 | and, if possible, try a current development snapshot. If you want to |
| 38 | report a bug with versions of GCC before 3.4 we strongly recommend |
| 39 | upgrading to the current release first. |
| 40 | |
| 41 | Before reporting that GCC compiles your code incorrectly, please |
| 42 | compile it with gcc -Wall and see whether this shows anything wrong |
| 43 | with your code that could be the cause instead of a bug in GCC. |
| 44 | |
| 45 | Summarized bug reporting instructions |
| 46 | |
| 47 | After this summary, you'll find detailed bug reporting instructions, |
| 48 | that explain how to obtain some of the information requested in this |
| 49 | summary. |
| 50 | |
| 51 | What we need |
| 52 | |
| 53 | Please include in your bug report all of the following items, the |
| 54 | first three of which can be obtained from the output of gcc -v: |
| 55 | * the exact version of GCC; |
| 56 | * the system type; |
| 57 | * the options given when GCC was configured/built; |
| 58 | * the complete command line that triggers the bug; |
| 59 | * the compiler output (error messages, warnings, etc.); and |
| 60 | * the preprocessed file (*.i*) that triggers the bug, generated by |
| 61 | adding -save-temps to the complete compilation command, or, in the |
| 62 | case of a bug report for the GNAT front end, a complete set of |
| 63 | source files (see below). |
| 64 | |
| 65 | What we do not want |
| 66 | |
| 67 | * A source file that #includes header files that are left out of the |
| 68 | bug report (see above) |
| 69 | * That source file and a collection of header files. |
| 70 | * An attached archive (tar, zip, shar, whatever) containing all (or |
| 71 | some :-) of the above. |
| 72 | * A code snippet that won't cause the compiler to produce the exact |
| 73 | output mentioned in the bug report (e.g., a snippet with just a |
| 74 | few lines around the one that apparently triggers the bug, with |
| 75 | some pieces replaced with ellipses or comments for extra |
| 76 | obfuscation :-) |
| 77 | * The location (URL) of the package that failed to build (we won't |
| 78 | download it, anyway, since you've already given us what we need to |
| 79 | duplicate the bug, haven't you? :-) |
| 80 | * An error that occurs only some of the times a certain file is |
| 81 | compiled, such that retrying a sufficient number of times results |
| 82 | in a successful compilation; this is a symptom of a hardware |
| 83 | problem, not of a compiler bug (sorry) |
| 84 | * Assembly files (*.s) produced by the compiler, or any binary |
| 85 | files, such as object files, executables, core files, or |
| 86 | precompiled header files |
| 87 | * Duplicate bug reports, or reports of bugs already fixed in the |
| 88 | development tree, especially those that have already been reported |
| 89 | as fixed last week :-) |
| 90 | * Bugs in the assembler, the linker or the C library. These are |
| 91 | separate projects, with separate mailing lists and different bug |
| 92 | reporting procedures |
| 93 | * Bugs in releases or snapshots of GCC not issued by the GNU |
| 94 | Project. Report them to whoever provided you with the release |
| 95 | * Questions about the correctness or the expected behavior of |
| 96 | certain constructs that are not GCC extensions. Ask them in forums |
| 97 | dedicated to the discussion of the programming language |
| 98 | |
| 99 | Where to post it |
| 100 | |
| 101 | Please submit your bug report directly to the [20]GCC bug database. |
| 102 | Alternatively, you can use the gccbug script that mails your bug |
| 103 | report to the bug database. |
| 104 | Only if all this is absolutely impossible, mail all information to |
| 105 | [21]gcc-bugs@gcc.gnu.org. |
| 106 | |
| 107 | Detailed bug reporting instructions |
| 108 | |
| 109 | Please refer to the [22]next section when reporting bugs in GNAT, the |
| 110 | Ada compiler, or to the [23]one after that when reporting bugs that |
| 111 | appear when using a precompiled header. |
| 112 | |
| 113 | In general, all the information we need can be obtained by collecting |
| 114 | the command line below, as well as its output and the preprocessed |
| 115 | file it generates. |
| 116 | |
| 117 | gcc -v -save-temps all-your-options source-file |
| 118 | |
| 119 | The only excuses to not send us the preprocessed sources are (i) if |
| 120 | you've found a bug in the preprocessor, (ii) if you've reduced the |
| 121 | testcase to a small file that doesn't include any other file or (iii) |
| 122 | if the bug appears only when using precompiled headers. If you can't |
| 123 | post the preprocessed sources because they're proprietary code, then |
| 124 | try to create a small file that triggers the same problem. |
| 125 | |
| 126 | Since we're supposed to be able to re-create the assembly output |
| 127 | (extension .s), you usually should not include it in the bug report, |
| 128 | although you may want to post parts of it to point out assembly code |
| 129 | you consider to be wrong. |
| 130 | |
| 131 | Please avoid posting an archive (.tar, .shar or .zip); we generally |
| 132 | need just a single file to reproduce the bug (the .i/.ii/.f |
| 133 | preprocessed file), and, by storing it in an archive, you're just |
| 134 | making our volunteers' jobs harder. Only when your bug report requires |
| 135 | multiple source files to be reproduced should you use an archive. This |
| 136 | is, for example, the case if you are using INCLUDE directives in |
| 137 | Fortran code, which are not processed by the preprocessor, but the |
| 138 | compiler. In that case, we need the main file and all INCLUDEd files. |
| 139 | In any case, make sure the compiler version, error message, etc, are |
| 140 | included in the body of your bug report as plain text, even if |
| 141 | needlessly duplicated as part of an archive. |
| 142 | |
| 143 | Detailed bug reporting instructions for GNAT |
| 144 | |
| 145 | See the [24]previous section for bug reporting instructions for GCC |
| 146 | language implementations other than Ada. |
| 147 | |
| 148 | Bug reports have to contain at least the following information in |
| 149 | order to be useful: |
| 150 | * the exact version of GCC, as shown by "gcc -v"; |
| 151 | * the system type; |
| 152 | * the options when GCC was configured/built; |
| 153 | * the exact command line passed to the gcc program triggering the |
| 154 | bug (not just the flags passed to gnatmake, but gnatmake prints |
| 155 | the parameters it passed to gcc) |
| 156 | * a collection of source files for reproducing the bug, preferably a |
| 157 | minimal set (see below); |
| 158 | * a description of the expected behavior; |
| 159 | * a description of actual behavior. |
| 160 | |
| 161 | If your code depends on additional source files (usually package |
| 162 | specifications), submit the source code for these compilation units in |
| 163 | a single file that is acceptable input to gnatchop, i.e. contains no |
| 164 | non-Ada text. If the compilation terminated normally, you can usually |
| 165 | obtain a list of dependencies using the "gnatls -d main_unit" command, |
| 166 | where main_unit is the file name of the main compilation unit (which |
| 167 | is also passed to gcc). |
| 168 | |
| 169 | If you report a bug which causes the compiler to print a bug box, |
| 170 | include that bug box in your report, and do not forget to send all the |
| 171 | source files listed after the bug box along with your report. |
| 172 | |
| 173 | If you use gnatprep, be sure to send in preprocessed sources (unless |
| 174 | you have to report a bug in gnatprep). |
| 175 | |
| 176 | When you have checked that your report meets these criteria, please |
| 177 | submit it according to our [25]generic instructions. (If you use a |
| 178 | mailing list for reporting, please include an "[Ada]" tag in the |
| 179 | subject.) |
| 180 | |
| 181 | Detailed bug reporting instructions when using a precompiled header |
| 182 | |
| 183 | If you're encountering a bug when using a precompiled header, the |
| 184 | first thing to do is to delete the precompiled header, and try running |
| 185 | the same GCC command again. If the bug happens again, the bug doesn't |
| 186 | really involve precompiled headers, please report it without using |
| 187 | them by following the instructions [26]above. |
| 188 | |
| 189 | If you've found a bug while building a precompiled header (for |
| 190 | instance, the compiler crashes), follow the usual instructions |
| 191 | [27]above. |
| 192 | |
| 193 | If you've found a real precompiled header bug, what we'll need to |
| 194 | reproduce it is the sources to build the precompiled header (as a |
| 195 | single .i file), the source file that uses the precompiled header, any |
| 196 | other headers that source file includes, and the command lines that |
| 197 | you used to build the precompiled header and to use it. |
| 198 | |
| 199 | Please don't send us the actual precompiled header. It is likely to be |
| 200 | very large and we can't use it to reproduce the problem. |
| 201 | _________________________________________________________________ |
| 202 | |
| 203 | Frequently Reported Bugs in GCC |
| 204 | |
| 205 | This is a list of bugs in GCC that are reported very often, but not |
| 206 | yet fixed. While it is certainly better to fix bugs instead of |
| 207 | documenting them, this document might save people the effort of |
| 208 | writing a bug report when the bug is already well-known. |
| 209 | |
| 210 | There are many reasons why a reported bug doesn't get fixed. It might |
| 211 | be difficult to fix, or fixing it might break compatibility. Often, |
| 212 | reports get a low priority when there is a simple work-around. In |
| 213 | particular, bugs caused by invalid code have a simple work-around: fix |
| 214 | the code. |
| 215 | _________________________________________________________________ |
| 216 | |
| 217 | C++ |
| 218 | |
| 219 | Missing features |
| 220 | |
| 221 | The export keyword is not implemented. |
| 222 | Most C++ compilers (G++ included) do not yet implement export, |
| 223 | which is necessary for separate compilation of template |
| 224 | declarations and definitions. Without export, a template |
| 225 | definition must be in scope to be used. The obvious workaround |
| 226 | is simply to place all definitions in the header itself. |
| 227 | Alternatively, the compilation unit containing template |
| 228 | definitions may be included from the header. |
| 229 | |
| 230 | Bugs fixed in the 3.4 series |
| 231 | |
| 232 | The following bugs are present up to (and including) GCC 3.3.x. They |
| 233 | have been fixed in 3.4.0. |
| 234 | |
| 235 | Two-stage name-lookup. |
| 236 | GCC did not implement two-stage name-lookup (also see |
| 237 | [28]below). |
| 238 | |
| 239 | Covariant return types. |
| 240 | GCC did not implement non-trivial covariant returns. |
| 241 | |
| 242 | Parse errors for "simple" code. |
| 243 | GCC gave parse errors for seemingly simple code, such as |
| 244 | |
| 245 | struct A |
| 246 | { |
| 247 | A(); |
| 248 | A(int); |
| 249 | }; |
| 250 | |
| 251 | struct B |
| 252 | { |
| 253 | B(A); |
| 254 | B(A,A); |
| 255 | void foo(); |
| 256 | }; |
| 257 | |
| 258 | A bar() |
| 259 | { |
| 260 | B b(A(),A(1)); // Variable b, initialized with two temporaries |
| 261 | B(A(2)).foo(); // B temporary, initialized with A temporary |
| 262 | return (A()); // return A temporary |
| 263 | } |
| 264 | |
| 265 | Although being valid code, each of the three lines with a |
| 266 | comment was rejected by GCC. The work-arounds for older |
| 267 | compiler versions proposed below do not change the semantics of |
| 268 | the programs at all. |
| 269 | |
| 270 | The problem in the first case was that GCC started to parse the |
| 271 | declaration of b as a function called b returning B, taking a |
| 272 | function returning A as an argument. When it encountered the 1, |
| 273 | it was too late. To show the compiler that this should be |
| 274 | really an expression, a comma operator with a dummy argument |
| 275 | could be used: |
| 276 | |
| 277 | B b((0,A()),A(1)); |
| 278 | |
| 279 | The work-around for simpler cases like the second one was to |
| 280 | add additional parentheses around the expressions that were |
| 281 | mistaken as declarations: |
| 282 | |
| 283 | (B(A(2))).foo(); |
| 284 | |
| 285 | In the third case, however, additional parentheses were causing |
| 286 | the problems: The compiler interpreted A() as a function |
| 287 | (taking no arguments, returning A), and (A()) as a cast lacking |
| 288 | an expression to be casted, hence the parse error. The |
| 289 | work-around was to omit the parentheses: |
| 290 | |
| 291 | return A(); |
| 292 | |
| 293 | This problem occurred in a number of variants; in throw |
| 294 | statements, people also frequently put the object in |
| 295 | parentheses. |
| 296 | _________________________________________________________________ |
| 297 | |
| 298 | Fortran |
| 299 | |
| 300 | G77 bugs are documented in the G77 manual rather than explicitly |
| 301 | listed here. Please see [29]Known Causes of Trouble with GNU Fortran |
| 302 | in the G77 manual. |
| 303 | _________________________________________________________________ |
| 304 | |
| 305 | Non-bugs |
| 306 | |
| 307 | The following are not actually bugs, but are reported often enough to |
| 308 | warrant a mention here. |
| 309 | |
| 310 | It is not always a bug in the compiler, if code which "worked" in a |
| 311 | previous version, is now rejected. Earlier versions of GCC sometimes |
| 312 | were less picky about standard conformance and accepted invalid source |
| 313 | code. In addition, programming languages themselves change, rendering |
| 314 | code invalid that used to be conforming (this holds especially for |
| 315 | C++). In either case, you should update your code to match recent |
| 316 | language standards. |
| 317 | _________________________________________________________________ |
| 318 | |
| 319 | General |
| 320 | |
| 321 | Problems with floating point numbers - the [30]most often reported |
| 322 | non-bug. |
| 323 | In a number of cases, GCC appears to perform floating point |
| 324 | computations incorrectly. For example, the C++ program |
| 325 | |
| 326 | #include <iostream> |
| 327 | |
| 328 | int main() |
| 329 | { |
| 330 | double a = 0.5; |
| 331 | double b = 0.01; |
| 332 | std::cout << (int)(a / b) << std::endl; |
| 333 | return 0; |
| 334 | } |
| 335 | |
| 336 | might print 50 on some systems and optimization levels, and 49 |
| 337 | on others. |
| 338 | |
| 339 | This is the result of rounding: The computer cannot represent |
| 340 | all real numbers exactly, so it has to use approximations. When |
| 341 | computing with approximation, the computer needs to round to |
| 342 | the nearest representable number. |
| 343 | |
| 344 | This is not a bug in the compiler, but an inherent limitation |
| 345 | of the floating point types. Please study [31]this paper for |
| 346 | more information. |
| 347 | _________________________________________________________________ |
| 348 | |
| 349 | C |
| 350 | |
| 351 | Increment/decrement operator (++/--) not working as expected - a |
| 352 | [32]problem with many variations. |
| 353 | The following expressions have unpredictable results: |
| 354 | |
| 355 | x[i]=++i |
| 356 | foo(i,++i) |
| 357 | i*(++i) /* special case with foo=="operator*" */ |
| 358 | std::cout << i << ++i /* foo(foo(std::cout,i),++i) */ |
| 359 | |
| 360 | since the i without increment can be evaluated before or after |
| 361 | ++i. |
| 362 | |
| 363 | The C and C++ standards have the notion of "sequence points". |
| 364 | Everything that happens between two sequence points happens in |
| 365 | an unspecified order, but it has to happen after the first and |
| 366 | before the second sequence point. The end of a statement and a |
| 367 | function call are examples for sequence points, whereas |
| 368 | assignments and the comma between function arguments are not. |
| 369 | |
| 370 | Modifying a value twice between two sequence points as shown in |
| 371 | the following examples is even worse: |
| 372 | |
| 373 | i=++i |
| 374 | foo(++i,++i) |
| 375 | (++i)*(++i) /* special case with foo=="operator*" */ |
| 376 | std::cout << ++i << ++i /* foo(foo(std::cout,++i),++i) */ |
| 377 | |
| 378 | This leads to undefined behavior (i.e. the compiler can do |
| 379 | anything). |
| 380 | |
| 381 | Casting does not work as expected when optimization is turned on. |
| 382 | This is often caused by a violation of aliasing rules, which |
| 383 | are part of the ISO C standard. These rules say that a program |
| 384 | is invalid if you try to access a variable through a pointer of |
| 385 | an incompatible type. This is happening in the following |
| 386 | example where a short is accessed through a pointer to integer |
| 387 | (the code assumes 16-bit shorts and 32-bit ints): |
| 388 | |
| 389 | #include <stdio.h> |
| 390 | |
| 391 | int main() |
| 392 | { |
| 393 | short a[2]; |
| 394 | |
| 395 | a[0]=0x1111; |
| 396 | a[1]=0x1111; |
| 397 | |
| 398 | *(int *)a = 0x22222222; /* violation of aliasing rules */ |
| 399 | |
| 400 | printf("%x %x\n", a[0], a[1]); |
| 401 | return 0; |
| 402 | } |
| 403 | |
| 404 | The aliasing rules were designed to allow compilers more |
| 405 | aggressive optimization. Basically, a compiler can assume that |
| 406 | all changes to variables happen through pointers or references |
| 407 | to variables of a type compatible to the accessed variable. |
| 408 | Dereferencing a pointer that violates the aliasing rules |
| 409 | results in undefined behavior. |
| 410 | |
| 411 | In the case above, the compiler may assume that no access |
| 412 | through an integer pointer can change the array a, consisting |
| 413 | of shorts. Thus, printf may be called with the original values |
| 414 | of a[0] and a[1]. What really happens is up to the compiler and |
| 415 | may change with architecture and optimization level. |
| 416 | |
| 417 | Recent versions of GCC turn on the option -fstrict-aliasing |
| 418 | (which allows alias-based optimizations) by default with -O2. |
| 419 | And some architectures then really print "1111 1111" as result. |
| 420 | Without optimization the executable will generate the |
| 421 | "expected" output "2222 2222". |
| 422 | |
| 423 | To disable optimizations based on alias-analysis for faulty |
| 424 | legacy code, the option -fno-strict-aliasing can be used as a |
| 425 | work-around. |
| 426 | |
| 427 | The option -Wstrict-aliasing (which is included in -Wall) warns |
| 428 | about some - but not all - cases of violation of aliasing rules |
| 429 | when -fstrict-aliasing is active. |
| 430 | |
| 431 | To fix the code above, you can use a union instead of a cast |
| 432 | (note that this is a GCC extension which might not work with |
| 433 | other compilers): |
| 434 | |
| 435 | #include <stdio.h> |
| 436 | |
| 437 | int main() |
| 438 | { |
| 439 | union |
| 440 | { |
| 441 | short a[2]; |
| 442 | int i; |
| 443 | } u; |
| 444 | |
| 445 | u.a[0]=0x1111; |
| 446 | u.a[1]=0x1111; |
| 447 | |
| 448 | u.i = 0x22222222; |
| 449 | |
| 450 | printf("%x %x\n", u.a[0], u.a[1]); |
| 451 | return 0; |
| 452 | } |
| 453 | |
| 454 | Now the result will always be "2222 2222". |
| 455 | |
| 456 | For some more insight into the subject, please have a look at |
| 457 | [33]this article. |
| 458 | |
| 459 | Cannot use preprocessor directive in macro arguments. |
| 460 | Let me guess... you used an older version of GCC to compile |
| 461 | code that looks something like this: |
| 462 | |
| 463 | memcpy(dest, src, |
| 464 | #ifdef PLATFORM1 |
| 465 | 12 |
| 466 | #else |
| 467 | 24 |
| 468 | #endif |
| 469 | ); |
| 470 | |
| 471 | and you got a whole pile of error messages: |
| 472 | |
| 473 | test.c:11: warning: preprocessing directive not recognized within macro arg |
| 474 | test.c:11: warning: preprocessing directive not recognized within macro arg |
| 475 | test.c:11: warning: preprocessing directive not recognized within macro arg |
| 476 | test.c: In function `foo': |
| 477 | test.c:6: undefined or invalid # directive |
| 478 | test.c:8: undefined or invalid # directive |
| 479 | test.c:9: parse error before `24' |
| 480 | test.c:10: undefined or invalid # directive |
| 481 | |
| 482 | This is because your C library's <string.h> happens to define |
| 483 | memcpy as a macro - which is perfectly legitimate. In recent |
| 484 | versions of glibc, for example, printf is among those functions |
| 485 | which are implemented as macros. |
| 486 | |
| 487 | Versions of GCC prior to 3.3 did not allow you to put #ifdef |
| 488 | (or any other preprocessor directive) inside the arguments of a |
| 489 | macro. The code therefore would not compile. |
| 490 | |
| 491 | As of GCC 3.3 this kind of construct is always accepted and the |
| 492 | preprocessor will probably do what you expect, but see the |
| 493 | manual for detailed semantics. |
| 494 | |
| 495 | However, this kind of code is not portable. It is "undefined |
| 496 | behavior" according to the C standard; that means different |
| 497 | compilers may do different things with it. It is always |
| 498 | possible to rewrite code which uses conditionals inside macros |
| 499 | so that it doesn't. You could write the above example |
| 500 | |
| 501 | #ifdef PLATFORM1 |
| 502 | memcpy(dest, src, 12); |
| 503 | #else |
| 504 | memcpy(dest, src, 24); |
| 505 | #endif |
| 506 | |
| 507 | This is a bit more typing, but I personally think it's better |
| 508 | style in addition to being more portable. |
| 509 | |
| 510 | Cannot initialize a static variable with stdin. |
| 511 | This has nothing to do with GCC, but people ask us about it a |
| 512 | lot. Code like this: |
| 513 | |
| 514 | #include <stdio.h> |
| 515 | |
| 516 | FILE *yyin = stdin; |
| 517 | |
| 518 | will not compile with GNU libc, because stdin is not a |
| 519 | constant. This was done deliberately, to make it easier to |
| 520 | maintain binary compatibility when the type FILE needs to be |
| 521 | changed. It is surprising for people used to traditional Unix C |
| 522 | libraries, but it is permitted by the C standard. |
| 523 | |
| 524 | This construct commonly occurs in code generated by old |
| 525 | versions of lex or yacc. We suggest you try regenerating the |
| 526 | parser with a current version of flex or bison, respectively. |
| 527 | In your own code, the appropriate fix is to move the |
| 528 | initialization to the beginning of main. |
| 529 | |
| 530 | There is a common misconception that the GCC developers are |
| 531 | responsible for GNU libc. These are in fact two entirely |
| 532 | separate projects; please check the [34]GNU libc web pages for |
| 533 | details. |
| 534 | _________________________________________________________________ |
| 535 | |
| 536 | C++ |
| 537 | |
| 538 | Nested classes can access private members and types of the containing |
| 539 | class. |
| 540 | Defect report 45 clarifies that nested classes are members of |
| 541 | the class they are nested in, and so are granted access to |
| 542 | private members of that class. |
| 543 | |
| 544 | G++ emits two copies of constructors and destructors. |
| 545 | In general there are three types of constructors (and |
| 546 | destructors). |
| 547 | |
| 548 | 1. The complete object constructor/destructor. |
| 549 | 2. The base object constructor/destructor. |
| 550 | 3. The allocating constructor/deallocating destructor. |
| 551 | |
| 552 | The first two are different, when virtual base classes are |
| 553 | involved. |
| 554 | |
| 555 | Global destructors are not run in the correct order. |
| 556 | Global destructors should be run in the reverse order of their |
| 557 | constructors completing. In most cases this is the same as the |
| 558 | reverse order of constructors starting, but sometimes it is |
| 559 | different, and that is important. You need to compile and link |
| 560 | your programs with --use-cxa-atexit. We have not turned this |
| 561 | switch on by default, as it requires a cxa aware runtime |
| 562 | library (libc, glibc, or equivalent). |
| 563 | |
| 564 | Classes in exception specifiers must be complete types. |
| 565 | [15.4]/1 tells you that you cannot have an incomplete type, or |
| 566 | pointer to incomplete (other than cv void *) in an exception |
| 567 | specification. |
| 568 | |
| 569 | Exceptions don't work in multithreaded applications. |
| 570 | You need to rebuild g++ and libstdc++ with --enable-threads. |
| 571 | Remember, C++ exceptions are not like hardware interrupts. You |
| 572 | cannot throw an exception in one thread and catch it in |
| 573 | another. You cannot throw an exception from a signal handler |
| 574 | and catch it in the main thread. |
| 575 | |
| 576 | Templates, scoping, and digraphs. |
| 577 | If you have a class in the global namespace, say named X, and |
| 578 | want to give it as a template argument to some other class, say |
| 579 | std::vector, then std::vector<::X> fails with a parser error. |
| 580 | |
| 581 | The reason is that the standard mandates that the sequence <: |
| 582 | is treated as if it were the token [. (There are several such |
| 583 | combinations of characters - they are called digraphs.) |
| 584 | Depending on the version, the compiler then reports a parse |
| 585 | error before the character : (the colon before X) or a missing |
| 586 | closing bracket ]. |
| 587 | |
| 588 | The simplest way to avoid this is to write std::vector< ::X>, |
| 589 | i.e. place a space between the opening angle bracket and the |
| 590 | scope operator. |
| 591 | |
| 592 | Copy constructor access check while initializing a reference. |
| 593 | Consider this code: |
| 594 | |
| 595 | class A |
| 596 | { |
| 597 | public: |
| 598 | A(); |
| 599 | |
| 600 | private: |
| 601 | A(const A&); // private copy ctor |
| 602 | }; |
| 603 | |
| 604 | A makeA(void); |
| 605 | void foo(const A&); |
| 606 | |
| 607 | void bar(void) |
| 608 | { |
| 609 | foo(A()); // error, copy ctor is not accessible |
| 610 | foo(makeA()); // error, copy ctor is not accessible |
| 611 | |
| 612 | A a1; |
| 613 | foo(a1); // OK, a1 is a lvalue |
| 614 | } |
| 615 | |
| 616 | Starting with GCC 3.4.0, binding an rvalue to a const reference |
| 617 | requires an accessible copy constructor. This might be |
| 618 | surprising at first sight, especially since most popular |
| 619 | compilers do not correctly implement this rule. |
| 620 | |
| 621 | The C++ Standard says that a temporary object should be created |
| 622 | in this context and its contents filled with a copy of the |
| 623 | object we are trying to bind to the reference; it also says |
| 624 | that the temporary copy can be elided, but the semantic |
| 625 | constraints (eg. accessibility) of the copy constructor still |
| 626 | have to be checked. |
| 627 | |
| 628 | For further information, you can consult the following |
| 629 | paragraphs of the C++ standard: [dcl.init.ref]/5, bullet 2, |
| 630 | sub-bullet 1, and [class.temporary]/2. |
| 631 | |
| 632 | Common problems when upgrading the compiler |
| 633 | |
| 634 | ABI changes |
| 635 | |
| 636 | The C++ application binary interface (ABI) consists of two components: |
| 637 | the first defines how the elements of classes are laid out, how |
| 638 | functions are called, how function names are mangled, etc; the second |
| 639 | part deals with the internals of the objects in libstdc++. Although we |
| 640 | strive for a non-changing ABI, so far we have had to modify it with |
| 641 | each major release. If you change your compiler to a different major |
| 642 | release you must recompile all libraries that contain C++ code. If you |
| 643 | fail to do so you risk getting linker errors or malfunctioning |
| 644 | programs. Some of our Java support libraries also contain C++ code, so |
| 645 | you might want to recompile all libraries to be safe. It should not be |
| 646 | necessary to recompile if you have changed to a bug-fix release of the |
| 647 | same version of the compiler; bug-fix releases are careful to avoid |
| 648 | ABI changes. See also the [35]compatibility section of the GCC manual. |
| 649 | |
| 650 | Remark: A major release is designated by a change to the first or |
| 651 | second component of the two- or three-part version number. A minor |
| 652 | (bug-fix) release is designated by a change to the third component |
| 653 | only. Thus GCC 3.2 and 3.3 are major releases, while 3.3.1 and 3.3.2 |
| 654 | are bug-fix releases for GCC 3.3. With the 3.4 series we are |
| 655 | introducing a new naming scheme; the first release of this series is |
| 656 | 3.4.0 instead of just 3.4. |
| 657 | |
| 658 | Standard conformance |
| 659 | |
| 660 | With each release, we try to make G++ conform closer to the ISO C++ |
| 661 | standard (available at [36]http://www.ncits.org/cplusplus.htm). We |
| 662 | have also implemented some of the core and library defect reports |
| 663 | (available at |
| 664 | [37]http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html & |
| 665 | [38]http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html |
| 666 | respectively). |
| 667 | |
| 668 | Non-conforming legacy code that worked with older versions of GCC may |
| 669 | be rejected by more recent compilers. There is no command-line switch |
| 670 | to ensure compatibility in general, because trying to parse |
| 671 | standard-conforming and old-style code at the same time would render |
| 672 | the C++ frontend unmaintainable. However, some non-conforming |
| 673 | constructs are allowed when the command-line option -fpermissive is |
| 674 | used. |
| 675 | |
| 676 | Two milestones in standard conformance are GCC 3.0 (including a major |
| 677 | overhaul of the standard library) and the 3.4.0 version (with its new |
| 678 | C++ parser). |
| 679 | |
| 680 | New in GCC 3.0 |
| 681 | |
| 682 | * The standard library is much more conformant, and uses the std:: |
| 683 | namespace (which is now a real namespace, not an alias for ::). |
| 684 | * The standard header files for the c library don't end with .h, but |
| 685 | begin with c (i.e. <cstdlib> rather than <stdlib.h>). The .h names |
| 686 | are still available, but are deprecated. |
| 687 | * <strstream> is deprecated, use <sstream> instead. |
| 688 | * streambuf::seekoff & streambuf::seekpos are private, instead use |
| 689 | streambuf::pubseekoff & streambuf::pubseekpos respectively. |
| 690 | * If std::operator << (std::ostream &, long long) doesn't exist, you |
| 691 | need to recompile libstdc++ with --enable-long-long. |
| 692 | |
| 693 | If you get lots of errors about things like cout not being found, |
| 694 | you've most likely forgotten to tell the compiler to look in the std:: |
| 695 | namespace. There are several ways to do this: |
| 696 | * Say std::cout at the call. This is the most explicit way of saying |
| 697 | what you mean. |
| 698 | * Say using std::cout; somewhere before the call. You will need to |
| 699 | do this for each function or type you wish to use from the |
| 700 | standard library. |
| 701 | * Say using namespace std; somewhere before the call. This is the |
| 702 | quick-but-dirty fix. This brings the whole of the std:: namespace |
| 703 | into scope. Never do this in a header file, as every user of your |
| 704 | header file will be affected by this decision. |
| 705 | |
| 706 | New in GCC 3.4.0 |
| 707 | |
| 708 | The new parser brings a lot of improvements, especially concerning |
| 709 | name-lookup. |
| 710 | * The "implicit typename" extension got removed (it was already |
| 711 | deprecated since GCC 3.1), so that the following code is now |
| 712 | rejected, see [14.6]: |
| 713 | |
| 714 | template <typename> struct A |
| 715 | { |
| 716 | typedef int X; |
| 717 | }; |
| 718 | |
| 719 | template <typename T> struct B |
| 720 | { |
| 721 | A<T>::X x; // error |
| 722 | typename A<T>::X y; // OK |
| 723 | }; |
| 724 | |
| 725 | B<void> b; |
| 726 | |
| 727 | * For similar reasons, the following code now requires the template |
| 728 | keyword, see [14.2]: |
| 729 | |
| 730 | template <typename> struct A |
| 731 | { |
| 732 | template <int> struct X {}; |
| 733 | }; |
| 734 | |
| 735 | template <typename T> struct B |
| 736 | { |
| 737 | typename A<T>::X<0> x; // error |
| 738 | typename A<T>::template X<0> y; // OK |
| 739 | }; |
| 740 | |
| 741 | B<void> b; |
| 742 | |
| 743 | * We now have two-stage name-lookup, so that the following code is |
| 744 | rejected, see [14.6]/9: |
| 745 | |
| 746 | template <typename T> int foo() |
| 747 | { |
| 748 | return i; // error |
| 749 | } |
| 750 | |
| 751 | * This also affects members of base classes, see [14.6.2]: |
| 752 | |
| 753 | template <typename> struct A |
| 754 | { |
| 755 | int i, j; |
| 756 | }; |
| 757 | |
| 758 | template <typename T> struct B : A<T> |
| 759 | { |
| 760 | int foo1() { return i; } // error |
| 761 | int foo2() { return this->i; } // OK |
| 762 | int foo3() { return B<T>::i; } // OK |
| 763 | int foo4() { return A<T>::i; } // OK |
| 764 | |
| 765 | using A<T>::j; |
| 766 | int foo5() { return j; } // OK |
| 767 | }; |
| 768 | |
| 769 | In addition to the problems listed above, the manual contains a |
| 770 | section on [39]Common Misunderstandings with GNU C++. |
| 771 | |
| 772 | References |
| 773 | |
| 774 | 1. http://gcc.gnu.org/bugs.html |
| 775 | 2. http://gcc.gnu.org/bugs.html#report |
| 776 | 3. http://gcc.gnu.org/bugs.html#need |
| 777 | 4. http://gcc.gnu.org/bugs.html#dontwant |
| 778 | 5. http://gcc.gnu.org/bugs.html#where |
| 779 | 6. http://gcc.gnu.org/bugs.html#detailed |
| 780 | 7. http://gcc.gnu.org/bugs.html#gnat |
| 781 | 8. http://gcc.gnu.org/bugs.html#pch |
| 782 | 9. http://gcc.gnu.org/bugs.html#known |
| 783 | 10. http://gcc.gnu.org/bugs.html#cxx |
| 784 | 11. http://gcc.gnu.org/bugs.html#missing |
| 785 | 12. http://gcc.gnu.org/bugs.html#fixed34 |
| 786 | 13. http://gcc.gnu.org/bugs.html#fortran |
| 787 | 14. http://gcc.gnu.org/bugs.html#nonbugs |
| 788 | 15. http://gcc.gnu.org/bugs.html#nonbugs_general |
| 789 | 16. http://gcc.gnu.org/bugs.html#nonbugs_c |
| 790 | 17. http://gcc.gnu.org/bugs.html#nonbugs_cxx |
| 791 | 18. http://gcc.gnu.org/bugs.html#upgrading |
| 792 | 19. http://gcc.gnu.org/bugs.html#known |
| 793 | 20. http://gcc.gnu.org/bugzilla/ |
| 794 | 21. mailto:gcc-bugs@gcc.gnu.org |
| 795 | 22. http://gcc.gnu.org/bugs.html#gnat |
| 796 | 23. http://gcc.gnu.org/bugs.html#pch |
| 797 | 24. http://gcc.gnu.org/bugs.html#detailed |
| 798 | 25. http://gcc.gnu.org/bugs.html#where |
| 799 | 26. http://gcc.gnu.org/bugs.html#detailed |
| 800 | 27. http://gcc.gnu.org/bugs.html#detailed |
| 801 | 28. http://gcc.gnu.org/bugs.html#new34 |
| 802 | 29. http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Trouble.html |
| 803 | 30. http://gcc.gnu.org/PR323 |
| 804 | 31. http://www.validlab.com/goldberg/paper.ps |
| 805 | 32. http://gcc.gnu.org/PR11751 |
| 806 | 33. http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html |
| 807 | 34. http://www.gnu.org/software/libc/ |
| 808 | 35. http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html |
| 809 | 36. http://www.ncits.org/cplusplus.htm |
| 810 | 37. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html |
| 811 | 38. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html |
| 812 | 39. http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html |