aboutsummaryrefslogtreecommitdiffstats
path: root/gcc-4.2.1/BUGS
diff options
context:
space:
mode:
Diffstat (limited to 'gcc-4.2.1/BUGS')
-rw-r--r--gcc-4.2.1/BUGS781
1 files changed, 0 insertions, 781 deletions
diff --git a/gcc-4.2.1/BUGS b/gcc-4.2.1/BUGS
deleted file mode 100644
index debcddc34..000000000
--- a/gcc-4.2.1/BUGS
+++ /dev/null
@@ -1,781 +0,0 @@
-
- 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