Context Navigation

-              r1390
+              r1391
    The latest version of this document is always available at
    [1]http://www.gnu.org/software/gcc/bugs.html.
+   [1]http://gcc.gnu.org/bugs.html.
      _________________________________________________________________
 …
           + [8]Detailed bug reporting instructions when using a
             precompiled header
+     * [9]Managing Bugs (GNATS and the test-suite)
+     * [10]Frequently Reported Bugs in GCC
+          + [11]General
+          + [12]Fortran
+          + [13]C
+          + [14]C++
+               o [15]Common problems updating from G++ 2.95 to G++ 3.0
+               o [16]Non-bugs
+               o [17]Missing features
+               o [18]Parse errors for "simple" code
+               o [19]Optimization at -O3 takes a very long time
+     * [9]Frequently Reported Bugs in GCC
+          + [10]C++
+               o [11]Missing features
+               o [12]Bugs fixed in the upcoming 3.4 series
+          + [13]Fortran
+     * [14]Non-bugs
+          + [15]General
+          + [16]C
+          + [17]C++
+               o [18]Common problems when upgrading the compiler
      _________________________________________________________________
                                 Reporting Bugs
+   Our preferred way of receiving bugs is via the [20]GCC GNATS bug
+   reporting system.
+   Before you report a bug, please check the [21]list of well-known 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, which we explain in detail below.
+   Before you report a bug, please check the [19]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
 …
   Where to post it
+   Please submit your bug report directly to the [22]GCC GNATS bug
+   database. Only if this is not possible, mail all information to
+   [23]bug-gcc@gnu.org or [24]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 [25]GCC GNATS bug database.
+   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 [26]next section when reporting bugs in GNAT, the
    Ada compiler, or to the [27]one after that when reporting bugs that
+   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.
 …
      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.
+   Typically the preprocessed file (extension .i for C or .ii for C++,
+   and .f if the preprocessor is used on Fortran files) 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
 …
    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.
+   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.
    If you fail to supply enough information for a bug report to be
 …
 Detailed bug reporting instructions for GNAT
    See the [28]previous section for bug reporting instructions for GCC
+   See the [24]previous section for bug reporting instructions for GCC
    language implementations other than Ada.
 …
    When you have checked that your report meets these criteria, please
    submit it according to our [29]generic instructions. (If you use a
+   submit it according to our [25]generic instructions. (If you use a
    mailing list for reporting, please include an "[Ada]" tag in the
    subject.)
 …
    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 [30]above.
+   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
    [31]above.
+   [27]above.
    If you've found a real precompiled header bug, what we'll need to
 …
    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.
-                   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):
-. Create a (minimal) test-case.
-. Add the test-case to our test-suite, marking it as XFAIL unless
-       the bug is a regression.
-. Add a bug report referencing the test-case to GNATS.
-   If you fix a bug for which there is already a GNATS entry:
-. Remove the XFAIL on the test-case.
-. Close the bug report in GNATS.
-   If you find a bug, and you are fixing it right then:
-. Create a (minimal) test-case.
-. Add the test-case to our test-suite, marking it as PASS.
-. Check in your fixes.
      _________________________________________________________________
                         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 upcoming 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 occured in a number of variants; in throw
+          statements, people also frequently put the object in
+          parentheses.
+     _________________________________________________________________
 Fortran
    Fortran bugs are documented in the G77 manual rather than explicitly
    listed here. Please see [32]Known Causes of Trouble with GNU Fortran
+   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.
+          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 floating point types. Please study [31]this paper for
+          more information.
+     _________________________________________________________________
+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:
+   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>
+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 [33]GNU libc web pages for
+          details.
+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
+          [32]this article.
    Cannot use preprocessor directive in macro arguments.
+          Let me guess... you wrote code that looks something like this:
+          Let me guess... you used an older version of GCC to compile
+          code that looks something like this:
   memcpy(dest, src,
 …
           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
+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
 …
           style in addition to being more portable.
+          In recent versions of glibc, printf is among the functions
+          which are implemented as macros.
+   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 [33]GNU libc web pages for
+          details.
      _________________________________________________________________
 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. [34]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
+   [35]http://www.ncits.org/cplusplus.htm).
+   We have also implemented some of the core and library defect reports
+   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).
+. The complete object constructor/destructor.
+. The base object constructor/destructor.
+. 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.
+  Common problems when upgrading the compiler
+    ABI changes
+   The application binary interface (ABI) defines how the elements of
+   classes are laid out, how functions are called, how function names are
+   mangled etc. It usually changes with each major release (i.e. when the
+   first or second part of the version number changes). You must
+   recompile all C++ libraries, or you risk linker errors or
+   malfunctioning programs. However, the ABI is not changed with bug-fix
+   releases (i.e. when the third part of the version number changes). The
+   code should be binary compatible among these versions.
+    Standard conformance
+   With each release, we try to make G++ conform 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
    [36]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html &
    [37]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
+   [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).
+   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 upcoming 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.
+     * std:: is now a real namespace, not an alias for ::.
+       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
 …
        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
+   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
+     * 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
+.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
+.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).
+. The complete object constructor/destructor.
+. The base object constructor/destructor.
+. 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 [38]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();
+       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;
 };
+struct B{
+  B(A);
   B(A,A);
   void func();
+template <typename T> struct B
+{
+    A<T>::X          x;  // error
+    typename A<T>::X y;  // OK
 };
+void foo(){
+  B b(A(),A(1));     //Variable b, initialized with two temporaries
+  B(A(2)).func();    //B temporary, initialized with A temporary
+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
+}
+   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);
+     * This also affects members of base classes, see [14.6.2]:
+template <typename> struct A
+{
+    int i, j;
 };
+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.
+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 [37]Common Misunderstandings with GNU C++.
 References
 . http://www.gnu.org/software/gcc/bugs.html
+. http://gcc.gnu.org/bugs.html
 . http://gcc.gnu.org/bugs.html#report
 . http://gcc.gnu.org/bugs.html#need
 …
 . http://gcc.gnu.org/bugs.html#gnat
 . http://gcc.gnu.org/bugs.html#pch
+. http://gcc.gnu.org/bugs.html#manage
+. http://gcc.gnu.org/bugs.html#known
+. http://gcc.gnu.org/bugs.html#general
+. http://gcc.gnu.org/bugs.html#fortran
+. http://gcc.gnu.org/bugs.html#c
+. http://gcc.gnu.org/bugs.html#cplusplus
+. http://gcc.gnu.org/bugs.html#updating
+. http://gcc.gnu.org/bugs.html#nonbugs
+. http://gcc.gnu.org/bugs.html#missing
+. http://gcc.gnu.org/bugs.html#parsing
+. http://gcc.gnu.org/bugs.html#-O3
+. http://gcc.gnu.org/gnats.html
+. http://gcc.gnu.org/bugs.html#known
+. http://gcc.gnu.org/gnats.html
+. mailto:bug-gcc@gnu.org
+. mailto:gcc-bugs@gcc.gnu.org
+. http://gcc.gnu.org/gnats.html
+. http://gcc.gnu.org/bugs.html#gnat
+. http://gcc.gnu.org/bugs.html#pch
+. http://gcc.gnu.org/bugs.html#detailed
+. http://gcc.gnu.org/bugs.html#where
+. http://gcc.gnu.org/bugs.html#detailed
+. http://gcc.gnu.org/bugs.html#detailed
+. http://gcc.gnu.org/onlinedocs/g77/Trouble.html
+. http://www.gnu.org/software/glibc/
+. http://gcc.gnu.org/bugs.html#report
+. http://www.ncits.org/cplusplus.htm
+. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html
+. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
+. http://www.validlab.com/goldberg/paper.ps
+. http://gcc.gnu.org/bugs.html#known
+. http://gcc.gnu.org/bugs.html#cxx
+. http://gcc.gnu.org/bugs.html#missing
+. http://gcc.gnu.org/bugs.html#fixed34
+. http://gcc.gnu.org/bugs.html#fortran
+. http://gcc.gnu.org/bugs.html#nonbugs
+. http://gcc.gnu.org/bugs.html#nonbugs_general
+. http://gcc.gnu.org/bugs.html#nonbugs_c
+. http://gcc.gnu.org/bugs.html#nonbugs_cxx
+. http://gcc.gnu.org/bugs.html#upgrading
+. http://gcc.gnu.org/bugs.html#known
+. http://gcc.gnu.org/bugzilla/
+. mailto:gcc-bugs@gcc.gnu.org
+. http://gcc.gnu.org/bugs.html#gnat
+. http://gcc.gnu.org/bugs.html#pch
+. http://gcc.gnu.org/bugs.html#detailed
+. http://gcc.gnu.org/bugs.html#where
+. http://gcc.gnu.org/bugs.html#detailed
+. http://gcc.gnu.org/bugs.html#detailed
+. http://gcc.gnu.org/bugs.html#new34
+. http://gcc.gnu.org/onlinedocs/g77/Trouble.html
+. http://gcc.gnu.org/PR323
+. http://www.validlab.com/goldberg/paper.ps
+. http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html
+. http://www.gnu.org/software/libc/
+. http://www.ncits.org/cplusplus.htm
+. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html
+. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
+. http://gcc.gnu.org/onlinedocs/gcc/C---Misunderstandings.html

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 1391 for branches/GNU/src/gcc/BUGS

Legend:

branches/GNU/src/gcc

branches/GNU/src/gcc/BUGS

Download in other formats: