diff options
Diffstat (limited to 'contrib/gcc/BUGS')
| -rw-r--r-- | contrib/gcc/BUGS | 594 |
1 files changed, 594 insertions, 0 deletions
diff --git a/contrib/gcc/BUGS b/contrib/gcc/BUGS new file mode 100644 index 0000000000000..d58a2296888af --- /dev/null +++ b/contrib/gcc/BUGS @@ -0,0 +1,594 @@ + + GCC Bugs + + The latest version of this document is always available at + [1]http://www.gnu.org/software/gcc/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]Managing Bugs (GNATS and the test-suite) + * [9]Frequently Reported Bugs in GCC + + [10]General + + [11]Fortran + + [12]C + + [13]C++ + o [14]Common problems updating from G++ 2.95 to G++ 3.0 + o [15]Non-bugs + o [16]Missing features + o [17]Parse errors for "simple" code + o [18]Optimization at -O3 takes a very long time + _________________________________________________________________ + + Reporting Bugs + + Our preferred way of receiving bugs is via the [19]GCC GNATS bug + reporting system. + + Before you report a bug, please check the [20]list of well-known bugs + and, if possible in any way, try a current development snapshot. If + you want to report a bug with versions of GCC before 3.1 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) + * E-mail messages that complement previous, incomplete bug reports. + Post a new, self-contained, full bug report instead, if possible + as a follow-up to the original bug report + * Assembly files (*.s) produced by the compiler, or any binary + files, such as object files, executables or core 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 [21]GCC GNATS bug + database. Only if this is not possible, mail all information to + [22]bug-gcc@gnu.org or [23]gcc-bugs@gcc.gnu.org. + + The GCC lists have message size limits (200 kbytes) and bug reports + over those limits will currently be bounced. If your bug is larger + than that, please post it using the [24]GCC GNATS bug database. + +Detailed bug reporting instructions + + Please refer to the [25]next section when reporting bugs in GNAT, the + Ada compiler. + + 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 + + Typically the preprocessed file (extension .i for C or .ii for C++) + will be large, so please compress the resulting file with one of the + popular compression programs such as bzip2, gzip, zip or compress (in + decreasing order of preference). Use maximum compression (-9) if + available. Please include the compressed preprocessor output in your + bug report, even if the source code is freely available elsewhere; it + makes the job of our volunteer testers much easier. + + The only excuses to not send us the preprocessed sources are (i) if + you've found a bug in the preprocessor, or (ii) if you've reduced the + testcase to a small file that doesn't include any other file. 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. + + Whether to use MIME attachments or uuencode is up to you. In any case, + make sure the compiler command line, version and error output are in + plain text, so that we don't have to decode the bug report in order to + tell who should take care of it. A meaningful subject indicating + language and platform also helps. + + Please avoid posting an archive (.tar, .shar or .zip); we generally + need just a single file to reproduce the bug (the .i/.ii 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. 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. + + If you fail to supply enough information for a bug report to be + reproduced, someone will probably ask you to post additional + information (or just ignore your bug report, if they're in a bad day, + so try to get it right on the first posting :-). In this case, please + post the additional information to the bug reporting mailing list, not + just to the person who requested it, unless explicitly told so. If + possible, please include in this follow-up all the information you had + supplied in the incomplete bug report (including the preprocessor + output), so that the new bug report is self-contained. + +Detailed bug reporting instructions for GNAT + + See the [26]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 accoding to our [27]generic instructions. (If you use a + mailing list for reporting, please include an "[Ada]" tag in the + subject.) + + Managing Bugs (GNATS and the test-suite) + + This section contains information mostly intended for GCC + contributors. + + If you find a bug, but you are not fixing it (yet): + 1. Create a (minimal) test-case. + 2. Add the test-case to our test-suite, marking it as XFAIL unless + the bug is a regression. + 3. Add a bug report referencing the test-case to GNATS. + + If you fix a bug for which there is already a GNATS entry: + 1. Remove the XFAIL on the test-case. + 2. Close the bug report in GNATS. + + If you find a bug, and you are fixing it right then: + 1. Create a (minimal) test-case. + 2. Add the test-case to our test-suite, marking it as PASS. + 3. Check in your fixes. + _________________________________________________________________ + + Frequently Reported Bugs in GCC + +Fortran + + Fortran bugs are documented in the G77 manual rather than explicitly + listed here. Please see [28]Known Causes of Trouble with GNU Fortran + in the G77 manual. + _________________________________________________________________ + +C + + The following are not bugs in the C compiler, but are reported often + enough to warrant a mention here. + + 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 (GNU/Linux libc6), 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 [29]GNU libc web pages for + details. + + Cannot use preprocessor directive in macro arguments. + Let me guess... you wrote 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 + test.c:11: parse error before `#' + + Update: As of GCC 3.2 this kind of construct is always accepted + and CPP will probably do what you expect, but see the manual + for detailed semantics. + + However, versions of GCC prior to 3.2 did not allow you to put + #ifdef (or any other directive) inside the arguments of a + macro. Your C library's <string.h> happens to define memcpy as + a macro - this is perfectly legitimate. The code therefore + would not compile. + + This kind of code is not portable. It is "undefined behavior" + according to the C standard; that means different compilers + will 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. + + In recent versions of glibc, printf is among the functions + which are implemented as macros. + _________________________________________________________________ + +C++ + + This is the list of bugs (and non-bugs) in g++ (aka GNU C++) 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. [30]How to report bugs tells you how to report a bug. + + There are many reasons why reported bugs don'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 C++ code have a simple work-around, + fix the code. Now that there is an agreed ISO/ANSI standard for C++, + the compiler has a definitive document to adhere to. Earlier versions + might have accepted source code that is no longer C++. This means that + code which might have `worked' in a previous version, is now rejected. + You should update your code to be C++. + + You should try to use the latest stable release of the GNU C++ + compiler. + + Common problems updating from G++ 2.95 to G++ 3.0 + + G++ 3.0 conforms much closer to the ISO C++ standard (available at + [31]http://www.ncits.org/cplusplus.htm). + + We have also implemented some of the core and library defect reports + (available at + [32]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html & + [33]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html + respectively). + * The ABI has changed. This means that both class layout and name + mangling is different. You must recompile all c++ libraries (if + you don't you will get link errors). + * The standard library is much more conformant, and uses the std:: + namespace. + * std:: 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. + + This means you may get lots of errors about things like strcmp not + being found. You've most likely forgotton to tell the compiler to look + in the std:: namespace. There are several ways to do this, + * Say, std::strcmp at the call. This is the most explicit way of + saying what you mean. + * Say, using std::strcmp; 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 you will be forcing + users of your header file to do the same. + + ABI bugs + + 3.0 had a new ABI, which affected class layout, function mangling and + calling conventions. We had intended it to be complete, unfortunately + some issues came to light, too late to fix in the 3.0 series. The ABI + should not change in dot releases, so we addressed most issues in GCC + 3.1. + + Covariant return types + We do not implement non-trivial covariant returns. We also + generate incorrect virtual function tables for trivial + covariance. Although trivial covariance will work, it is + incompatible with the ABI. GNATS PR 3706 tracks this problem. + + Non-bugs + + Here are some features that have been reported as bugs, but are not. + + Nested classes can access private types of the containing class. + G++ now implements type access control on member types. 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. + + 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. + + 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 destructor/deallocating destructor. + + The first two are different, when virtual base classes are + involved. In some cases we can do better, and this is logged in + GNATS. + + 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. + + 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). + + Problems with floating point computations. + In a number of cases, GCC appears to perform floating point + computations incorrectly. For example, the program + + #include <iostream> + int main() { + double min = 0.0; + double max = 0.5; + double width = 0.01; + std::cout << (int)(((max - min) / width) - 1) << std::endl; + } + + might print 50 on some systems and optimization levels, and 51 + on others. + + The 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 float and double types. Please study [34]this paper for + more information. + + Templates, scoping, and digraphs. + If you have a class in global namespace, say named X, and want + to give it as a template argument to some other class, say + std::vector, then this here fails with a parser error: + std::vector<::X>. + + The reason is that the standard mandates that the sequence <: + is treated as if it were the token [, and the parser then + reports a parse error before the character : (by which it means + the second colon). There are several such combinations of + characters, and they are called digraphs. + + 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. + + Missing features + + We know some things are missing from G++. + + 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. + + Two stage lookup in templates is not implemented. + [14.6] specifies how names are looked up inside a template. G++ + does not do this correctly, but for most templates this will + not be noticeable. + + Parse errors for "simple" code + + Up to and including GCC 3.0, the compiler will give "parse error" for + seemingly simple code, such as +struct A{ + A(); + A(int); + void func(); +}; + +struct B{ + B(A); + B(A,A); + void func(); +}; + +void foo(){ + B b(A(),A(1)); //Variable b, initialized with two temporaries + B(A(2)).func(); //B temporary, initialized with A temporary +} + + The problem is that GCC starts to parse the declaration of b as a + function b returning B, taking a function returning A as an argument. + When it sees the 1, it is too late. The work-around in these cases is + to add additional parentheses around the expressions that are mistaken + as declarations: + (B(A(2))).func(); + + Sometimes, even that is not enough; to show the compiler that this + should be really an expression, a comma operator with a dummy argument + can be used: + B b((0,A()),A(1)); + + Another example is the parse error for the return statement in +struct A{}; + +struct B{ + A a; + A f1(bool); +}; + +A B::f1(bool b) +{ + if (b) + return (A()); + return a; +} + + The problem is that the compiler interprets A() as a function (taking + no arguments, returning A), and (A()) as a cast - with a missing + expression, hence the parse error. The work-around is to omit the + parentheses: + if (b) + return A(); + + This problem occurs in a number of variants; in throw statements, + people also frequently put the object in parentheses. The exact error + also somewhat varies with the compiler version. The work-arounds + proposed do not change the semantics of the program at all; they make + them perhaps less readable. + + Optimization at -O3 takes a very long time + + At -O3, all functions are candidates for inlining. The heuristic used + has some deficiencies which show up when allowed such freedom. This is + g++ specific, as it has an earlier inliner than gcc. + +References + + 1. http://www.gnu.org/software/gcc/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#manage + 9. http://gcc.gnu.org/bugs.html#known + 10. http://gcc.gnu.org/bugs.html#general + 11. http://gcc.gnu.org/bugs.html#fortran + 12. http://gcc.gnu.org/bugs.html#c + 13. http://gcc.gnu.org/bugs.html#cplusplus + 14. http://gcc.gnu.org/bugs.html#updating + 15. http://gcc.gnu.org/bugs.html#nonbugs + 16. http://gcc.gnu.org/bugs.html#missing + 17. http://gcc.gnu.org/bugs.html#parsing + 18. http://gcc.gnu.org/bugs.html#-O3 + 19. http://gcc.gnu.org/gnats.html + 20. http://gcc.gnu.org/bugs.html#known + 21. http://gcc.gnu.org/gnats.html + 22. mailto:bug-gcc@gnu.org + 23. mailto:gcc-bugs@gcc.gnu.org + 24. http://gcc.gnu.org/gnats.html + 25. http://gcc.gnu.org/bugs.html#gnat + 26. http://gcc.gnu.org/bugs.html#detailed + 27. http://gcc.gnu.org/bugs.html#where + 28. http://gcc.gnu.org/onlinedocs/g77/Trouble.html + 29. http://www.gnu.org/software/glibc/ + 30. http://gcc.gnu.org/bugs.html#report + 31. http://www.ncits.org/cplusplus.htm + 32. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html + 33. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html + 34. http://www.validlab.com/goldberg/paper.ps |