diff options
Diffstat (limited to 'gcc-4.2.1/BUGS')
| -rw-r--r-- | gcc-4.2.1/BUGS | 781 |
1 files changed, 781 insertions, 0 deletions
diff --git a/gcc-4.2.1/BUGS b/gcc-4.2.1/BUGS new file mode 100644 index 000000000..debcddc34 --- /dev/null +++ b/gcc-4.2.1/BUGS @@ -0,0 +1,781 @@ + + GCC Bugs + + The latest version of this document is always available at + [1]http://gcc.gnu.org/bugs.html. + _________________________________________________________________ + +Table of Contents + + * [2]Reporting Bugs + + [3]What we need + + [4]What we DON'T want + + [5]Where to post it + + [6]Detailed bug reporting instructions + + [7]Detailed bug reporting instructions for GNAT + + [8]Detailed bug reporting instructions when using a precompiled + header + * [9]Frequently Reported Bugs in GCC + + [10]C++ + o [11]Missing features + o [12]Bugs fixed in the 3.4 series + + [13]Fortran + * [14]Non-bugs + + [15]General + + [16]C + + [17]C++ + o [18]Common problems when upgrading the compiler + _________________________________________________________________ + + Reporting Bugs + + 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. + + Before you report a bug, please check the [19]list of well-known bugs and, + if possible, try a current development snapshot. If you want to report a bug + with versions of GCC before 3.4 we strongly recommend upgrading to the + current release first. + + Before reporting that GCC compiles your code incorrectly, please compile it + with gcc -Wall and see whether this shows anything wrong with your code that + could be the cause instead of a bug in GCC. + +Summarized bug reporting instructions + + After this summary, you'll find detailed bug reporting instructions, that + explain how to obtain some of the information requested in this summary. + + 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) + * 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 + + Where to post it + + Please submit your bug report directly to the [20]GCC bug database. + Alternatively, you can use the gccbug script that mails your bug report to + the bug database. + Only if all this is absolutely impossible, mail all information to + [21]gcc-bugs@gcc.gnu.org. + +Detailed bug reporting instructions + + Please refer to the [22]next section when reporting bugs in GNAT, the Ada + compiler, or to the [23]one after that when reporting bugs that appear when + using a precompiled header. + + In general, all the information we need can be obtained by collecting the + command line below, as well as its output and the preprocessed file it + generates. + + gcc -v -save-temps all-your-options source-file + + The only excuses to not send us the preprocessed sources are (i) if you've + found a bug in the preprocessor, (ii) if you've reduced the testcase to a + small file that doesn't include any other file or (iii) if the bug appears + only when using precompiled headers. If you can't post the preprocessed + sources because they're proprietary code, then try to create a small file + that triggers the same problem. + + Since we're supposed to be able to re-create the assembly output (extension + .s), you usually should not include it in the bug report, although you may + want to post parts of it to point out assembly code you consider to be + wrong. + + Please avoid posting an archive (.tar, .shar or .zip); we generally need + just a single file to reproduce the bug (the .i/.ii/.f preprocessed file), + and, by storing it in an archive, you're just making our volunteers' jobs + harder. Only when your bug report requires multiple source files to be + reproduced should you use an archive. This is, for example, the case if you + are using INCLUDE directives in Fortran code, which are not processed by the + preprocessor, but the compiler. In that case, we need the main file and all + INCLUDEd files. In any case, make sure the compiler version, error message, + etc, are included in the body of your bug report as plain text, even if + needlessly duplicated as part of an archive. + +Detailed bug reporting instructions for GNAT + + See the [24]previous section for bug reporting instructions for GCC language + implementations other than Ada. + + Bug reports have to contain at least the following information in order to + be useful: + * the exact version of GCC, as shown by "gcc -v"; + * the system type; + * the options when GCC was configured/built; + * the exact command line passed to the gcc program triggering the bug (not + just the flags passed to gnatmake, but gnatmake prints the parameters it + passed to gcc) + * a collection of source files for reproducing the bug, preferably a + minimal set (see below); + * a description of the expected behavior; + * a description of actual behavior. + + If your code depends on additional source files (usually package + specifications), submit the source code for these compilation units in a + single file that is acceptable input to gnatchop, i.e. contains no non-Ada + text. If the compilation terminated normally, you can usually obtain a list + of dependencies using the "gnatls -d main_unit" command, where main_unit is + the file name of the main compilation unit (which is also passed to gcc). + + If you report a bug which causes the compiler to print a bug box, include + that bug box in your report, and do not forget to send all the source files + listed after the bug box along with your report. + + If you use gnatprep, be sure to send in preprocessed sources (unless you + have to report a bug in gnatprep). + + When you have checked that your report meets these criteria, please submit + it according to our [25]generic instructions. (If you use a mailing list for + reporting, please include an "[Ada]" tag in the subject.) + +Detailed bug reporting instructions when using a precompiled header + + If you're encountering a bug when using a precompiled header, the first + thing to do is to delete the precompiled header, and try running the same + GCC command again. If the bug happens again, the bug doesn't really involve + precompiled headers, please report it without using them by following the + instructions [26]above. + + If you've found a bug while building a precompiled header (for instance, the + compiler crashes), follow the usual instructions [27]above. + + If you've found a real precompiled header bug, what we'll need to reproduce + it is the sources to build the precompiled header (as a single .i file), the + source file that uses the precompiled header, any other headers that source + file includes, and the command lines that you used to build the precompiled + header and to use it. + + Please don't send us the actual precompiled header. It is likely to be very + large and we can't use it to reproduce the problem. + _________________________________________________________________ + + Frequently Reported Bugs in GCC + + This is a list of bugs in GCC that are reported very often, but not yet + fixed. While it is certainly better to fix bugs instead of documenting them, + this document might save people the effort of writing a bug report when the + bug is already well-known. + + There are many reasons why a reported bug doesn't get fixed. It might be + difficult to fix, or fixing it might break compatibility. Often, reports get + a low priority when there is a simple work-around. In particular, bugs + caused by invalid code have a simple work-around: fix the code. + _________________________________________________________________ + +C++ + + Missing features + + The export keyword is not implemented. + Most C++ compilers (G++ included) do not yet implement export, which + is necessary for separate compilation of template declarations and + definitions. Without export, a template definition must be in scope + to be used. The obvious workaround is simply to place all definitions + in the header itself. Alternatively, the compilation unit containing + template definitions may be included from the header. + + Bugs fixed in the 3.4 series + + The following bugs are present up to (and including) GCC 3.3.x. They have + been fixed in 3.4.0. + + Two-stage name-lookup. + GCC did not implement two-stage name-lookup (also see [28]below). + + Covariant return types. + GCC did not implement non-trivial covariant returns. + + Parse errors for "simple" code. + GCC gave parse errors for seemingly simple code, such as + +struct A +{ + A(); + A(int); +}; + +struct B +{ + B(A); + B(A,A); + void foo(); +}; + +A bar() +{ + B b(A(),A(1)); // Variable b, initialized with two temporaries + B(A(2)).foo(); // B temporary, initialized with A temporary + return (A()); // return A temporary +} + + Although being valid code, each of the three lines with a comment was + rejected by GCC. The work-arounds for older compiler versions + proposed below do not change the semantics of the programs at all. + + The problem in the first case was that GCC started to parse the + declaration of b as a function called b returning B, taking a + function returning A as an argument. When it encountered the 1, it + was too late. To show the compiler that this should be really an + expression, a comma operator with a dummy argument could be used: + +B b((0,A()),A(1)); + + The work-around for simpler cases like the second one was to add + additional parentheses around the expressions that were mistaken as + declarations: + +(B(A(2))).foo(); + + In the third case, however, additional parentheses were causing the + problems: The compiler interpreted A() as a function (taking no + arguments, returning A), and (A()) as a cast lacking an expression to + be casted, hence the parse error. The work-around was to omit the + parentheses: + +return A(); + + This problem occurred in a number of variants; in throw statements, + people also frequently put the object in parentheses. + _________________________________________________________________ + +Fortran + + G77 bugs are documented in the G77 manual rather than explicitly listed + here. Please see [29]Known Causes of Trouble with GNU Fortran in the G77 + manual. + _________________________________________________________________ + + Non-bugs + + The following are not actually bugs, but are reported often enough to + warrant a mention here. + + It is not always a bug in the compiler, if code which "worked" in a previous + version, is now rejected. Earlier versions of GCC sometimes were less picky + about standard conformance and accepted invalid source code. In addition, + programming languages themselves change, rendering code invalid that used to + be conforming (this holds especially for C++). In either case, you should + update your code to match recent language standards. + _________________________________________________________________ + +General + + Problems with floating point numbers - the [30]most often reported non-bug. + In a number of cases, GCC appears to perform floating point + computations incorrectly. For example, the C++ program + +#include <iostream> + +int main() +{ + double a = 0.5; + double b = 0.01; + std::cout << (int)(a / b) << std::endl; + return 0; +} + + might print 50 on some systems and optimization levels, and 49 on + others. + + This is the result of rounding: The computer cannot represent all + real numbers exactly, so it has to use approximations. When computing + with approximation, the computer needs to round to the nearest + representable number. + + This is not a bug in the compiler, but an inherent limitation of the + floating point types. Please study [31]this paper for more + information. + _________________________________________________________________ + +C + + Increment/decrement operator (++/--) not working as expected - a [32]problem + with many variations. + The following expressions have unpredictable results: + +x[i]=++i +foo(i,++i) +i*(++i) /* special case with foo=="operator*" */ +std::cout << i << ++i /* foo(foo(std::cout,i),++i) */ + + since the i without increment can be evaluated before or after ++i. + + The C and C++ standards have the notion of "sequence points". + Everything that happens between two sequence points happens in an + unspecified order, but it has to happen after the first and before + the second sequence point. The end of a statement and a function call + are examples for sequence points, whereas assignments and the comma + between function arguments are not. + + Modifying a value twice between two sequence points as shown in the + following examples is even worse: + +i=++i +foo(++i,++i) +(++i)*(++i) /* special case with foo=="operator*" */ +std::cout << ++i << ++i /* foo(foo(std::cout,++i),++i) */ + + This leads to undefined behavior (i.e. the compiler can do anything). + + Casting does not work as expected when optimization is turned on. + This is often caused by a violation of aliasing rules, which are part + of the ISO C standard. These rules say that a program is invalid if + you try to access a variable through a pointer of an incompatible + type. This is happening in the following example where a short is + accessed through a pointer to integer (the code assumes 16-bit shorts + and 32-bit ints): + +#include <stdio.h> + +int main() +{ + short a[2]; + + a[0]=0x1111; + a[1]=0x1111; + + *(int *)a = 0x22222222; /* violation of aliasing rules */ + + printf("%x %x\n", a[0], a[1]); + return 0; +} + + The aliasing rules were designed to allow compilers more aggressive + optimization. Basically, a compiler can assume that all changes to + variables happen through pointers or references to variables of a + type compatible to the accessed variable. Dereferencing a pointer + that violates the aliasing rules results in undefined behavior. + + In the case above, the compiler may assume that no access through an + integer pointer can change the array a, consisting of shorts. Thus, + printf may be called with the original values of a[0] and a[1]. What + really happens is up to the compiler and may change with architecture + and optimization level. + + Recent versions of GCC turn on the option -fstrict-aliasing (which + allows alias-based optimizations) by default with -O2. And some + architectures then really print "1111 1111" as result. Without + optimization the executable will generate the "expected" output "2222 + 2222". + + To disable optimizations based on alias-analysis for faulty legacy + code, the option -fno-strict-aliasing can be used as a work-around. + + The option -Wstrict-aliasing (which is included in -Wall) warns about + some - but not all - cases of violation of aliasing rules when + -fstrict-aliasing is active. + + To fix the code above, you can use a union instead of a cast (note + that this is a GCC extension which might not work with other + compilers): + +#include <stdio.h> + +int main() +{ + union + { + short a[2]; + int i; + } u; + + u.a[0]=0x1111; + u.a[1]=0x1111; + + u.i = 0x22222222; + + printf("%x %x\n", u.a[0], u.a[1]); + return 0; +} + + Now the result will always be "2222 2222". + + For some more insight into the subject, please have a look at + [33]this article. + + Cannot use preprocessor directive in macro arguments. + Let me guess... you used an older version of GCC to compile code that + looks something like this: + + memcpy(dest, src, +#ifdef PLATFORM1 + 12 +#else + 24 +#endif + ); + + and you got a whole pile of error messages: + +test.c:11: warning: preprocessing directive not recognized within macro arg +test.c:11: warning: preprocessing directive not recognized within macro arg +test.c:11: warning: preprocessing directive not recognized within macro arg +test.c: In function `foo': +test.c:6: undefined or invalid # directive +test.c:8: undefined or invalid # directive +test.c:9: parse error before `24' +test.c:10: undefined or invalid # directive + + This is because your C library's <string.h> happens to define memcpy + as a macro - which is perfectly legitimate. In recent versions of + glibc, for example, printf is among those functions which are + implemented as macros. + + Versions of GCC prior to 3.3 did not allow you to put #ifdef (or any + other preprocessor directive) inside the arguments of a macro. The + code therefore would not compile. + + As of GCC 3.3 this kind of construct is always accepted and the + preprocessor will probably do what you expect, but see the manual for + detailed semantics. + + However, this kind of code is not portable. It is "undefined + behavior" according to the C standard; that means different compilers + may do different things with it. It is always possible to rewrite + code which uses conditionals inside macros so that it doesn't. You + could write the above example + +#ifdef PLATFORM1 + memcpy(dest, src, 12); +#else + memcpy(dest, src, 24); +#endif + + This is a bit more typing, but I personally think it's better style + in addition to being more portable. + + Cannot initialize a static variable with stdin. + This has nothing to do with GCC, but people ask us about it a lot. + Code like this: + +#include <stdio.h> + +FILE *yyin = stdin; + + will not compile with GNU libc, because stdin is not a constant. This + was done deliberately, to make it easier to maintain binary + compatibility when the type FILE needs to be changed. It is + surprising for people used to traditional Unix C libraries, but it is + permitted by the C standard. + + This construct commonly occurs in code generated by old versions of + lex or yacc. We suggest you try regenerating the parser with a + current version of flex or bison, respectively. In your own code, the + appropriate fix is to move the initialization to the beginning of + main. + + There is a common misconception that the GCC developers are + responsible for GNU libc. These are in fact two entirely separate + projects; please check the [34]GNU libc web pages for details. + _________________________________________________________________ + +C++ + + Nested classes can access private members and types of the containing class. + Defect report 45 clarifies that nested classes are members of the + class they are nested in, and so are granted access to private + members of that class. + + G++ emits two copies of constructors and destructors. + In general there are three types of constructors (and destructors). + + 1. The complete object constructor/destructor. + 2. The base object constructor/destructor. + 3. The allocating constructor/deallocating destructor. + + The first two are different, when virtual base classes are involved. + + Global destructors are not run in the correct order. + Global destructors should be run in the reverse order of their + constructors completing. In most cases this is the same as the + reverse order of constructors starting, but sometimes it is + different, and that is important. You need to compile and link your + programs with --use-cxa-atexit. We have not turned this switch on by + default, as it requires a cxa aware runtime library (libc, glibc, or + equivalent). + + Classes in exception specifiers must be complete types. + [15.4]/1 tells you that you cannot have an incomplete type, or + pointer to incomplete (other than cv void *) in an exception + specification. + + Exceptions don't work in multithreaded applications. + You need to rebuild g++ and libstdc++ with --enable-threads. + Remember, C++ exceptions are not like hardware interrupts. You cannot + throw an exception in one thread and catch it in another. You cannot + throw an exception from a signal handler and catch it in the main + thread. + + Templates, scoping, and digraphs. + If you have a class in the global namespace, say named X, and want to + give it as a template argument to some other class, say std::vector, + then std::vector<::X> fails with a parser error. + + The reason is that the standard mandates that the sequence <: is + treated as if it were the token [. (There are several such + combinations of characters - they are called digraphs.) Depending on + the version, the compiler then reports a parse error before the + character : (the colon before X) or a missing closing bracket ]. + + The simplest way to avoid this is to write std::vector< ::X>, i.e. + place a space between the opening angle bracket and the scope + operator. + + Copy constructor access check while initializing a reference. + Consider this code: + +class A +{ +public: + A(); + +private: + A(const A&); // private copy ctor +}; + +A makeA(void); +void foo(const A&); + +void bar(void) +{ + foo(A()); // error, copy ctor is not accessible + foo(makeA()); // error, copy ctor is not accessible + + A a1; + foo(a1); // OK, a1 is a lvalue +} + + Starting with GCC 3.4.0, binding an rvalue to a const reference + requires an accessible copy constructor. This might be surprising at + first sight, especially since most popular compilers do not correctly + implement this rule. + + The C++ Standard says that a temporary object should be created in + this context and its contents filled with a copy of the object we are + trying to bind to the reference; it also says that the temporary copy + can be elided, but the semantic constraints (eg. accessibility) of + the copy constructor still have to be checked. + + For further information, you can consult the following paragraphs of + the C++ standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and + [class.temporary]/2. + + Common problems when upgrading the compiler + + ABI changes + + The C++ application binary interface (ABI) consists of two components: the + first defines how the elements of classes are laid out, how functions are + called, how function names are mangled, etc; the second part deals with the + internals of the objects in libstdc++. Although we strive for a non-changing + ABI, so far we have had to modify it with each major release. If you change + your compiler to a different major release you must recompile all libraries + that contain C++ code. If you fail to do so you risk getting linker errors + or malfunctioning programs. Some of our Java support libraries also contain + C++ code, so you might want to recompile all libraries to be safe. It should + not be necessary to recompile if you have changed to a bug-fix release of + the same version of the compiler; bug-fix releases are careful to avoid ABI + changes. See also the [35]compatibility section of the GCC manual. + + Remark: A major release is designated by a change to the first or second + component of the two- or three-part version number. A minor (bug-fix) + release is designated by a change to the third component only. Thus GCC 3.2 + and 3.3 are major releases, while 3.3.1 and 3.3.2 are bug-fix releases for + GCC 3.3. With the 3.4 series we are introducing a new naming scheme; the + first release of this series is 3.4.0 instead of just 3.4. + + Standard conformance + + With each release, we try to make G++ conform closer to the ISO C++ standard + (available at [36]http://www.ncits.org/cplusplus.htm). We have also + implemented some of the core and library defect reports (available at + [37]http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html & + [38]http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html + respectively). + + Non-conforming legacy code that worked with older versions of GCC may be + rejected by more recent compilers. There is no command-line switch to ensure + compatibility in general, because trying to parse standard-conforming and + old-style code at the same time would render the C++ frontend + unmaintainable. However, some non-conforming constructs are allowed when the + command-line option -fpermissive is used. + + Two milestones in standard conformance are GCC 3.0 (including a major + overhaul of the standard library) and the 3.4.0 version (with its new C++ + parser). + + New in GCC 3.0 + + * The standard library is much more conformant, and uses the std:: + namespace (which is now a real namespace, not an alias for ::). + * The standard header files for the c library don't end with .h, but begin + with c (i.e. <cstdlib> rather than <stdlib.h>). The .h names are still + available, but are deprecated. + * <strstream> is deprecated, use <sstream> instead. + * streambuf::seekoff & streambuf::seekpos are private, instead use + streambuf::pubseekoff & streambuf::pubseekpos respectively. + * If std::operator << (std::ostream &, long long) doesn't exist, you need + to recompile libstdc++ with --enable-long-long. + + If you get lots of errors about things like cout not being found, you've + most likely forgotten to tell the compiler to look in the std:: namespace. + There are several ways to do this: + * Say std::cout at the call. This is the most explicit way of saying what + you mean. + * Say using std::cout; somewhere before the call. You will need to do this + for each function or type you wish to use from the standard library. + * Say using namespace std; somewhere before the call. This is the + quick-but-dirty fix. This brings the whole of the std:: namespace into + scope. Never do this in a header file, as every user of your header file + will be affected by this decision. + + New in GCC 3.4.0 + + The new parser brings a lot of improvements, especially concerning + name-lookup. + * The "implicit typename" extension got removed (it was already deprecated + since GCC 3.1), so that the following code is now rejected, see [14.6]: + +template <typename> struct A +{ + typedef int X; +}; + +template <typename T> struct B +{ + A<T>::X x; // error + typename A<T>::X y; // OK +}; + +B<void> b; + + * For similar reasons, the following code now requires the template + keyword, see [14.2]: + +template <typename> struct A +{ + template <int> struct X {}; +}; + +template <typename T> struct B +{ + typename A<T>::X<0> x; // error + typename A<T>::template X<0> y; // OK +}; + +B<void> b; + + * We now have two-stage name-lookup, so that the following code is + rejected, see [14.6]/9: + +template <typename T> int foo() +{ + return i; // error +} + + * This also affects members of base classes, see [14.6.2]: + +template <typename> struct A +{ + int i, j; +}; + +template <typename T> struct B : A<T> +{ + int foo1() { return i; } // error + int foo2() { return this->i; } // OK + int foo3() { return B<T>::i; } // OK + int foo4() { return A<T>::i; } // OK + + using A<T>::j; + int foo5() { return j; } // OK +}; + + In addition to the problems listed above, the manual contains a section on + [39]Common Misunderstandings with GNU C++. + +References + + 1. http://gcc.gnu.org/bugs.html + 2. http://gcc.gnu.org/bugs.html#report + 3. http://gcc.gnu.org/bugs.html#need + 4. http://gcc.gnu.org/bugs.html#dontwant + 5. http://gcc.gnu.org/bugs.html#where + 6. http://gcc.gnu.org/bugs.html#detailed + 7. http://gcc.gnu.org/bugs.html#gnat + 8. http://gcc.gnu.org/bugs.html#pch + 9. http://gcc.gnu.org/bugs.html#known + 10. http://gcc.gnu.org/bugs.html#cxx + 11. http://gcc.gnu.org/bugs.html#missing + 12. http://gcc.gnu.org/bugs.html#fixed34 + 13. http://gcc.gnu.org/bugs.html#fortran + 14. http://gcc.gnu.org/bugs.html#nonbugs + 15. http://gcc.gnu.org/bugs.html#nonbugs_general + 16. http://gcc.gnu.org/bugs.html#nonbugs_c + 17. http://gcc.gnu.org/bugs.html#nonbugs_cxx + 18. http://gcc.gnu.org/bugs.html#upgrading + 19. http://gcc.gnu.org/bugs.html#known + 20. http://gcc.gnu.org/bugzilla/ + 21. mailto:gcc-bugs@gcc.gnu.org + 22. http://gcc.gnu.org/bugs.html#gnat + 23. http://gcc.gnu.org/bugs.html#pch + 24. http://gcc.gnu.org/bugs.html#detailed + 25. http://gcc.gnu.org/bugs.html#where + 26. http://gcc.gnu.org/bugs.html#detailed + 27. http://gcc.gnu.org/bugs.html#detailed + 28. http://gcc.gnu.org/bugs.html#new34 + 29. http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Trouble.html + 30. http://gcc.gnu.org/PR323 + 31. http://www.validlab.com/goldberg/paper.ps + 32. http://gcc.gnu.org/PR11751 + 33. http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html + 34. http://www.gnu.org/software/libc/ + 35. http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html + 36. http://www.ncits.org/cplusplus.htm + 37. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html + 38. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html + 39. http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html |