diff options
Diffstat (limited to 'contrib/gcc/BUGS')
| -rw-r--r-- | contrib/gcc/BUGS | 594 |
1 files changed, 0 insertions, 594 deletions
diff --git a/contrib/gcc/BUGS b/contrib/gcc/BUGS deleted file mode 100644 index d58a229..0000000 --- a/contrib/gcc/BUGS +++ /dev/null @@ -1,594 +0,0 @@ - - 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 |
