+++ /dev/null
-
- 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]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, 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 [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, or to the [26]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
-
- 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, (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.
-
- 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 [27]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 [28]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 [29]above.
-
- If you've found a bug while building a precompiled header (for
- instance, the compiler crashes), follow the usual instructions
- [30]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
-
-Fortran
-
- Fortran bugs are documented in the G77 manual rather than explicitly
- listed here. Please see [31]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 [32]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. [33]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
- [34]http://www.ncits.org/cplusplus.htm).
-
- We have also implemented some of the core and library defect reports
- (available at
- [35]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html &
- [36]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 forgotten 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 49 on some systems and optimization levels, and 48
- 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 [37]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://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#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#pch
- 27. http://gcc.gnu.org/bugs.html#detailed
- 28. http://gcc.gnu.org/bugs.html#where
- 29. http://gcc.gnu.org/bugs.html#detailed
- 30. http://gcc.gnu.org/bugs.html#detailed
- 31. http://gcc.gnu.org/onlinedocs/g77/Trouble.html
- 32. http://www.gnu.org/software/glibc/
- 33. http://gcc.gnu.org/bugs.html#report
- 34. http://www.ncits.org/cplusplus.htm
- 35. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html
- 36. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
- 37. http://www.validlab.com/goldberg/paper.ps
projects / msp430-gcc.git / blobdiff