
                                   GCC Bugs

   The   latest   version   of  this  document  is  always  available  at
   [1]http://www.gnu.org/software/gcc/bugs.html.
     _________________________________________________________________

Table of Contents

     * [2]Reporting Bugs
          + [3]What we need
          + [4]What we DON'T want
          + [5]Where to post it
          + [6]Detailed bug reporting instructions
     * [7]Managing Bugs (GNATS and the test-suite)
     * [8]Frequently Reported Bugs in GCC 3.0
          + [9]General
          + [10]Fortran
          + [11]C
          + [12]C++
               o [13]Common problems updating from G++ 2.95 to G++ 3.0
               o [14]Non-bugs
               o [15]Missing features
               o [16]Parse errors for "simple" code
               o [17]Optimization at -O3 takes a very long time
     _________________________________________________________________

                                Reporting Bugs

   Our  preferred  way  of  receiving  bugs  is via the [18]GCC GNATS bug
   reporting system.

   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.0 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  (see
       below).

  What we do not want

     * A source file that #includes header files that are left out of the
       bug report (see above)
     * That source file and a collection of header files.
     * An  attached archive (tar, zip, shar, whatever) containing all (or
       some :-) of the above.
     * A  code snippet that won't cause the compiler to produce the exact
       output  mentioned  in  the bug report (e.g., a snippet with just a
       few  lines  around  the one that apparently triggers the bug, with
       some   pieces   replaced  with  ellipses  or  comments  for  extra
       obfuscation :-)
     * The  location  (URL) of the package that failed to build (we won't
       download it, anyway, since you've already given us what we need to
       duplicate the bug, haven't you? :-)
     * An  error  that  occurs  only  some of the times a certain file is
       compiled,  such that retrying a sufficient number of times results
       in  a  successful  compilation;  this  is  a symptom of a hardware
       problem, not of a compiler bug (sorry)
     * E-mail  messages that complement previous, incomplete bug reports.
       Post  a  new, self-contained, full bug report instead, if possible
       as a follow-up to the original bug report
     * Assembly  files  (*.s)  produced  by  the  compiler, or any binary
       files, such as object files, executables or core files
     * Duplicate  bug  reports,  or  reports of bugs already fixed in the
       development tree, especially those that have already been reported
       as fixed last week :-)
     * Bugs  in  the  assembler,  the  linker or the C library. These are
       separate  projects,  with separate mailing lists and different bug
       reporting procedures
     * Bugs  in  releases  or  snapshots  of  GCC  not  issued by the GNU
       Project. Report them to whoever provided you with the release
     * Questions  about  the  correctness  or  the  expected  behavior of
       certain constructs that are not GCC extensions. Ask them in forums
       dedicated to the discussion of the programming language

  Where to post it

   Please  submit  your  bug  report  directly  to  the [20]GCC GNATS bug
   database.  Only  if  this  is  not  possible,  mail all information to
   [21]bug-gcc@gnu.org or [22]gcc-bugs@gcc.gnu.org.

Detailed bug reporting instructions

   In  general, all the information we need can be obtained by collecting
   the  command  line  below,  as well as its output and the preprocessed
   file it generates.

     gcc -v -save-temps all-your-options source-file

   Typically  the  preprocessed  file (extension .i for C or .ii for C++)
   will  be  large, so please compress the resulting file with one of the
   popular  compression programs such as bzip2, gzip, zip or compress (in
   decreasing  order  of  preference).  Use  maximum  compression (-9) if
   available.  Please  include the compressed preprocessor output in your
   bug  report, even if the source code is freely available elsewhere; it
   makes the job of our volunteer testers much easier.

   The  only  excuses  to not send us the preprocessed sources are (i) if
   you've  found a bug in the preprocessor, or (ii) if you've reduced the
   testcase  to  a small file that doesn't include any other file. If you
   can't  post the preprocessed sources because they're proprietary code,
   then try to create a small file that triggers the same problem.

   Since  we're  supposed  to  be  able  to re-create the assembly output
   (extension  .s),  you usually should not include it in the bug report,
   although  you  may want to post parts of it to point out assembly code
   you consider to be wrong.

   Whether to use MIME attachments or uuencode is up to you. In any case,
   make  sure  the compiler command line, version and error output are in
   plain text, so that we don't have to decode the bug report in order to
   tell  who  should  take  care  of  it. A meaningful subject indicating
   language and platform also helps.

   Please  avoid  posting  an archive (.tar, .shar or .zip); we generally
   need  just a single file to reproduce the bug (the .i/.ii preprocessed
   file),  and,  by  storing  it  in  an  archive, you're just making our
   volunteers'  jobs  harder. Only when your bug report requires multiple
   source  files to be reproduced should you use an archive. In any case,
   make  sure  the  compiler version, error message, etc, are included in
   the  body  of  your  bug  report  as  plain  text,  even if needlessly
   duplicated as part of an archive.

   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 [23]GCC GNATS bug database.

   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.

                   Managing Bugs (GNATS and the test-suite)

   This   section   contains   information   mostly   intended   for  GCC
   contributors.

   If you find a bug, but you are not fixing it (yet):
    1. Create a (minimal) test-case.
    2. Add  the  test-case  to our test-suite, marking it as XFAIL unless
       the bug is a regression.
    3. Add a bug report referencing the test-case to GNATS.

   If you fix a bug for which there is already a GNATS entry:
    1. Remove the XFAIL on the test-case.
    2. Close the bug report in GNATS.

   If you find a bug, and you are fixing it right then:
    1. Create a (minimal) test-case.
    2. Add the test-case to our test-suite, marking it as PASS.
    3. Check in your fixes.
     _________________________________________________________________

                      Frequently Reported Bugs in GCC 3.0

General

   The following bugs are very frequently reported.
     * GCC  2.95.2  does  not build on GNU/Linux systems using glibc 2.2,
       such as Red Hat 7.0. This is fixed in GCC 2.95.3 and GCC 3.0.
     * GCC  2.95.2  crashes  when  compiling  mbx.c from the PINE 4.30 or
       IMAP2000 distribution on Sparc systems running Solaris.
     _________________________________________________________________

Fortran

   Fortran  bugs  are documented in the G77 manual rather than explicitly
   listed  here.  Please see [24]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 [25]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 `#'

          The  problem,  simply  put, is that GCC's preprocessor does 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 will not compile.

          We  have  two  good  reasons for not allowing directives inside
          macro  arguments.  First,  it is not portable. It is "undefined
          behavior"  according  to  the  C standard; that means different
          compilers  will do different things with it. Some will give you
          errors.  Some  will  dump  core. Some will silently mangle your
          code - you could get the equivalent of

        memcpy(dest, src, 1224);

          from  the  above example. A very few might do what you expected
          it  to.  We  therefore feel it is most useful for GCC to reject
          this construct immediately so that it is found and fixed.

          Second,  it  is  extraordinarily  difficult  to  implement  the
          preprocessor  such that it does what you would expect for every
          possible  directive  found  inside  a  macro argument. The best
          example is perhaps

     #define foo(arg) ... arg ...
     foo(blah
     #undef foo
     blah)

          which  is impossible to implement in portable C without leaking
          memory.   Allowing   only  a  subset  of  directives  would  be
          confusing.

          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. [26]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.  This  is  currently  3.0.  Many  commonly  reported bugs in
   earlier releases are fixed in that version.

  Common problems updating from G++ 2.95 to G++ 3.0

   G++  3.0  conforms  much  closer to the ISO C++ standard (available at
   [27]http://www.ncits.org/cplusplus.htm).

   We  have  also implemented some of the core and library defect reports
   (available at
   [28]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html      &
   [29]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
   respectively).
     * The  ABI  has  changed. This means that both class layout and name
       mangling  is  different.  You must recompile all c++ libraries (if
       you don't you will get link errors).
     * The  standard  library is much more conformant, and uses the std::
       namespace.
     * std:: is now a real namespace, not an alias for ::.
     * The standard header files for the c library don't end with .h, but
       begin with c (i.e. <cstdlib> rather than <stdlib.h>). The .h names
       are still available, but are deprecated.
     * <strstream> is deprecated, use <sstream> instead.
     * streambuf::seekoff  &  streambuf::seekpos are private, instead use
       streambuf::pubseekoff & streambuf::pubseekpos respectively.
     * If std::operator << (std::ostream &, long long) doesn't exist, you
       need to recompile libstdc++ with --enable-long-long.

   This  means  you  may  get lots of errors about things like strcmp not
   being found. You've most likely forgotton to tell the compiler to look
   in the std:: namespace. There are several ways to do this,
     * Say,  std::strcmp  at  the  call. This is the most explicit way of
       saying what you mean.
     * Say,  using  std::strcmp; somewhere before the call. You will need
       to  do  this  for  each  function or type you wish to use from the
       standard library.
     * Say,  using  namespace std; somewhere before the call. This is the
       quick-but-dirty  fix. This brings the whole of the std:: namespace
       into scope. Never do this in a header file, as you will be forcing
       users of your header file to do the same.

  ABI bugs

   3.0  has  a new ABI, which affects class layout, function mangling and
   calling  conventions. We had intended it to be complete, unfortunately
   some  issues  have  come  to light, too late to fix in the 3.0 series.
   Rather than fix them in subsequent 3.0 dot releases we have decided to
   fix these in the 3.1 development series. History has shown that it was
   a  mistake  to  make  ABI  changes in dot releases. Also, the standard
   library  will  also  change  in  the 3.1 series, which is effective as
   changing the ABI.

   Complicated virtual inheritance segfaults
          Some  instances  of  complicated virtual inheritance crash when
          executing  the constructor. We believe some cases to be already
          existing  in  g++  2.95, bug that generated incorrect code that
          didn't  happen to crash. Other cases concern polymophic virtual
          base  classes  with  no  data  members  (so called nearly empty
          bases).  You might be able to work around the problem by adding
          a  dummy  data  member. GNATS PRs 3598, 3290, 3145 & 2811 track
          these issues.

   Base classes with operator delete [] (void *, size_t) sometimes did
          not get the correct size passed when deleting a derived object
          This is a long standing G++ bug, that should have been fixed by
          the  new  ABI.  Unfortunately  it  did not, and requires an ABI
          change  to  fix. Also, a related, but more obscure case is when
          both  that  and  an  operator  delete[]  (void  *) is provided.
          Although  the  produced code functions, it is incompatible with
          the  ABI.  GNATS PR 113 tracked this, which is now fixed in the
          3.1 tree with [30]this patch.

   Covariant return types
          We  do  not  implement  non-trivial  covariant returns. We also
          generate   incorrect   virtual   function  tables  for  trivial
          covariance.  Although  trivial  covariance  will  work,  it  is
          incompatible with the ABI. GNATS PR 3706 tracks this problem.

  Non-bugs

   Here are some features that have been reported as bugs, but are not.

   Nested classes can access private types of the containing class.
          G++  now implements type access control on member types. Defect
          report  45  clarifies  that  nested  classes are members of the
          class  they are nested in, and so are granted access to private
          members of that class.

   Classes in exception specifiers must be complete types.
          [15.4]/1  tells you that you cannot have an incomplete type, or
          pointer  to  incomplete  (other than cv void *) in an exception
          specification.

   G++ emits two copies of constructors and destructors.
          In   general   there  are  three  types  of  constructors  (and
          destructors).

         1. The complete object constructor/destructor.
         2. The base object constructor/destructor.
         3. The allocating destructor/deallocating destructor.

          The  first  two  are  different,  when virtual base classes are
          involved. In some cases we can do better, and this is logged in
          GNATS.

   Exceptions don't work in multithreaded applications.
          You  need  to  rebuild g++ and libstdc++ with --enable-threads.
          Remember,  c++ exceptions are not like hardware interrupts. You
          cannot  throw  an  exception  in  one  thread  and  catch it in
          another.  You  cannot throw an exception from a signal handler,
          and catch it in the main thread.

   Global destructors are not run in the correct order.
          Global  destructors should be run in the reverse order of their
          constructors  completing. In most cases this is the same as the
          reverse  order  of  constructors  starting, but sometimes it is
          different,  and that is important. You need to compile and link
          your  programs  with  --use-cxa-atexit. We have not turned this
          switch  on  by  default,  as  it  requires  a cxa aware runtime
          library (libc, glibc, or equivalent).

   Problems with floating point computations.
          In  a  number  of  cases, GCC appears to perform floating point
          computations incorrectly. For example, the program

     #include <iostream>
     int main() {
     double min = 0.0;
     double max = 0.5;
     double width = 0.01;
     std::cout << (int)(((max - min) / width) - 1) << std::endl;
     }

          might  print 50 on some systems and optimization levels, and 51
          on others.

          The  is  the  result of rounding: The computer cannot represent
          all real numbers exactly, so it has to use approximations. When
          computing  with  approximation,  the computer needs to round to
          the nearest representable number.

          This  is  not a bug in the compiler, but an inherent limitation
          of  the float and double types. Please study [31]this paper for
          more information.

  Missing features

   We know some things are missing from G++.

   The export keyword is not implemented.
          Most  C++ compilers (G++ included) do not yet implement export,
          which   is  necessary  for  separate  compilation  of  template
          declarations   and  definitions.  Without  export,  a  template
          definition  must be in scope to be used. The obvious workaround
          is  simply  to  place  all  definitions  in  the header itself.
          Alternatively,   the   compilation   unit  containing  template
          definitions may be included from the header.

   Two stage lookup in templates is not implemented.
          [14.6] specifies how names are looked up inside a template. G++
          does  not  do  this correctly, but for most templates this will
          not be noticeable.

  Parse errors for "simple" code

   Up  to and including GCC 3.0, the compiler will give "parse error" for
   seemingly simple code, such as
struct A{
  A();
  A(int);
  void func();
};

struct B{
  B(A);
  B(A,A);
  void func();
};

void foo(){
  B b(A(),A(1));     //Variable b, initialized with two temporaries
  B(A(2)).func();    //B temporary, initialized with A temporary
}

   The  problem  is  that  GCC  starts to parse the declaration of b as a
   function  b returning B, taking a function returning A as an argument.
   When  it sees the 1, it is too late. The work-around in these cases is
   to add additional parentheses around the expressions that are mistaken
   as declarations:
  (B(A(2))).func();

   Sometimes,  even  that  is  not enough; to show the compiler that this
   should be really an expression, a comma operator with a dummy argument
   can be used:
  B b((0,A()),A(1));

   Another example is the parse error for the return statement in
struct A{};

struct B{
  A a;
  A f1(bool);
};

A B::f1(bool b)
{
  if (b)
    return (A());
  return a;
}

   The  problem is that the compiler interprets A() as a function (taking
   no  arguments,  returning  A),  and  (A())  as a cast - with a missing
   expression,  hence  the  parse  error.  The work-around is to omit the
   parentheses:
  if (b)
    return A();

   This  problem  occurs  in  a  number of variants; in throw statements,
   people  also frequently put the object in parentheses. The exact error
   also  somewhat  varies  with  the  compiler  version. The work-arounds
   proposed  do not change the semantics of the program at all; they make
   them perhaps less readable.

  Optimization at -O3 takes a very long time

   At  -O3, all functions are candidates for inlining. The heuristic used
   has some deficiencies which show up when allowed such freedom. This is
   g++ specific, as it has an earlier inliner than gcc.

References

   1. http://www.gnu.org/software/gcc/bugs.html
   2. http://gcc.gnu.org/bugs.html#report
   3. http://gcc.gnu.org/bugs.html#need
   4. http://gcc.gnu.org/bugs.html#dontwant
   5. http://gcc.gnu.org/bugs.html#where
   6. http://gcc.gnu.org/bugs.html#detailed
   7. http://gcc.gnu.org/bugs.html#manage
   8. http://gcc.gnu.org/bugs.html#known
   9. http://gcc.gnu.org/bugs.html#general
  10. http://gcc.gnu.org/bugs.html#fortran
  11. http://gcc.gnu.org/bugs.html#c
  12. http://gcc.gnu.org/bugs.html#cplusplus
  13. http://gcc.gnu.org/bugs.html#updating
  14. http://gcc.gnu.org/bugs.html#nonbugs
  15. http://gcc.gnu.org/bugs.html#missing
  16. http://gcc.gnu.org/bugs.html#parsing
  17. http://gcc.gnu.org/bugs.html#-O3
  18. http://gcc.gnu.org/gnats.html
  19. http://gcc.gnu.org/bugs.html#known
  20. http://gcc.gnu.org/gnats.html
  21. mailto:bug-gcc@gnu.org
  22. mailto:gcc-bugs@gcc.gnu.org
  23. http://gcc.gnu.org/gnats.html
  24. http://gcc.gnu.org/onlinedocs/g77_bugs.html
  25. http://www.gnu.org/software/glibc/
  26. http://gcc.gnu.org/bugs.html#report
  27. http://www.ncits.org/cplusplus.htm
  28. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html
  29. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
  30. http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01302.html
  31. http://www.validlab.com/goldberg/paper.ps
