source: trunk/third/gcc/BUGS @ 18474

                                   GCC Bugs

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

Table of Contents

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

                                Reporting Bugs

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

   Before  you report a bug, please check the [20]list of well-known bugs
   and,  if  possible  in any way, try a current development snapshot. If
   you  want  to report a bug with versions of GCC before 3.1 we strongly
   recommend upgrading to the current release first.

   Before  reporting  that  GCC  compiles  your  code incorrectly, please
   compile  it  with  gcc -Wall and see whether this shows anything wrong
   with your code that could be the cause instead of a bug in GCC.

Summarized bug reporting instructions

   After  this  summary, you'll find detailed bug reporting instructions,
   that  explain  how to obtain some of the information requested in this
   summary.

  What we need

   Please  include  in  your  bug  report all of the following items, the
   first three of which can be obtained from the output of gcc -v:
     * the exact version of GCC;
     * the system type;
     * the options given when GCC was configured/built;
     * the complete command line that triggers the bug;
     * the compiler output (error messages, warnings, etc.); and
     * the  preprocessed  file (*.i*) that triggers the bug, generated by
       adding -save-temps to the complete compilation command, or, in the
       case  of  a  bug  report for the GNAT front end, a complete set of
       source files (see below).

  What we do not want

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

  Where to post it

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

   The  GCC  lists  have message size limits (200 kbytes) and bug reports
   over  those  limits  will  currently be bounced. If your bug is larger
   than that, please post it using the [24]GCC GNATS bug database.

Detailed bug reporting instructions

   Please  refer to the [25]next section when reporting bugs in GNAT, the
   Ada compiler.

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

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

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

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

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

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

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

   If  you  fail  to  supply  enough  information  for a bug report to be
   reproduced,   someone   will  probably  ask  you  to  post  additional
   information  (or just ignore your bug report, if they're in a bad day,
   so  try to get it right on the first posting :-). In this case, please
   post the additional information to the bug reporting mailing list, not
   just  to  the  person  who requested it, unless explicitly told so. If
   possible, please include in this follow-up all the information you had
   supplied  in  the  incomplete  bug  report (including the preprocessor
   output), so that the new bug report is self-contained.

Detailed bug reporting instructions for GNAT

   See  the  [26]previous  section for bug reporting instructions for GCC
   language implementations other than Ada.

   Bug  reports  have  to  contain  at least the following information in
   order to be useful:
     * the exact version of GCC, as shown by "gcc -v";
     * the system type;
     * the options when GCC was configured/built;
     * the  exact  command  line passed to the gcc program triggering the
       bug  (not  just  the flags passed to gnatmake, but gnatmake prints
       the parameters it passed to gcc)
     * a collection of source files for reproducing the bug, preferably a
       minimal set (see below);
     * a description of the expected behavior;
     * a description of actual behavior.

   If  your  code  depends  on  additional  source files (usually package
   specifications), submit the source code for these compilation units in
   a  single  file that is acceptable input to gnatchop, i.e. contains no
   non-Ada  text. If the compilation terminated normally, you can usually
   obtain a list of dependencies using the "gnatls -d main_unit" command,
   where  main_unit  is the file name of the main compilation unit (which
   is also passed to gcc).

   If  you  report  a  bug  which causes the compiler to print a bug box,
   include that bug box in your report, and do not forget to send all the
   source files listed after the bug box along with your report.

   If  you  use gnatprep, be sure to send in preprocessed sources (unless
   you have to report a bug in gnatprep).

   When  you  have  checked that your report meets these criteria, please
   submit  it  accoding  to  our  [27]generic instructions. (If you use a
   mailing  list  for  reporting,  please  include  an "[Ada]" tag in the
   subject.)

                   Managing Bugs (GNATS and the test-suite)

   This   section   contains   information   mostly   intended   for  GCC
   contributors.

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

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

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

                        Frequently Reported Bugs in GCC

Fortran

   Fortran  bugs  are documented in the G77 manual rather than explicitly
   listed  here.  Please see [28]Known Causes of Trouble with GNU Fortran
   in the G77 manual.
     _________________________________________________________________

C

   The  following  are not bugs in the C compiler, but are reported often
   enough to warrant a mention here.

   Cannot initialize a static variable with stdin.
          This  has  nothing to do with GCC, but people ask us about it a
          lot. Code like this:

#include <stdio.h>

FILE *yyin = stdin;

          will not compile with GNU libc (GNU/Linux libc6), because stdin
          is  not  a  constant.  This  was  done deliberately, to make it
          easier  to  maintain  binary  compatibility  when the type FILE
          needs  to  be  changed.  It  is  surprising  for people used to
          traditional  Unix  C  libraries,  but  it is permitted by the C
          standard.

          This  construct  commonly  occurs  in  code  generated  by  old
          versions  of  lex  or yacc. We suggest you try regenerating the
          parser  with  a current version of flex or bison, respectively.
          In   your  own  code,  the  appropriate  fix  is  to  move  the
          initialization to the beginning of main.

          There  is  a  common  misconception that the GCC developers are
          responsible  for  GNU  libc.  These  are  in  fact two entirely
          separate  projects; please check the [29]GNU libc web pages for
          details.

   Cannot use preprocessor directive in macro arguments.
          Let me guess... you wrote code that looks something like this:

  memcpy(dest, src,
#ifdef PLATFORM1
         12
#else
         24
#endif
        );

          and you got a whole pile of error messages:

     test.c:11:  warning:  preprocessing directive not recognized within
     macro arg
     test.c:11:  warning:  preprocessing directive not recognized within
     macro arg
     test.c:11:  warning:  preprocessing directive not recognized within
     macro arg
     test.c: In function `foo':
     test.c:6: undefined or invalid # directive
     test.c:8: undefined or invalid # directive
     test.c:9: parse error before `24'
     test.c:10: undefined or invalid # directive
     test.c:11: parse error before `#'

          Update: As of GCC 3.2 this kind of construct is always accepted
          and  CPP  will  probably do what you expect, but see the manual
          for detailed semantics.

          However,  versions of GCC prior to 3.2 did not allow you to put
          #ifdef  (or  any  other  directive)  inside  the arguments of a
          macro.  Your C library's <string.h> happens to define memcpy as
          a  macro  -  this  is  perfectly legitimate. The code therefore
          would not compile.

          This  kind  of code is not portable. It is "undefined behavior"
          according  to  the  C  standard; that means different compilers
          will  do  different  things  with  it. It is always possible to
          rewrite  code  which uses conditionals inside macros so that it
          doesn't. You could write the above example

#ifdef PLATFORM1
   memcpy(dest, src, 12);
#else
   memcpy(dest, src, 24);
#endif

          This  is  a bit more typing, but I personally think it's better
          style in addition to being more portable.

          In  recent  versions  of  glibc,  printf is among the functions
          which are implemented as macros.
     _________________________________________________________________

C++

   This  is the list of bugs (and non-bugs) in g++ (aka GNU C++) that are
   reported  very  often, but not yet fixed. While it is certainly better
   to  fix  bugs  instead  of  documenting them, this document might save
   people  the  effort  of  writing  a bug report when the bug is already
   well-known. [30]How to report bugs tells you how to report a bug.

   There  are many reasons why reported bugs don't get fixed. It might be
   difficult  to  fix,  or  fixing  it  might break compatibility. Often,
   reports  get  a  low  priority  when there is a simple work-around. In
   particular, bugs caused by invalid C++ code have a simple work-around,
   fix  the  code. Now that there is an agreed ISO/ANSI standard for C++,
   the  compiler has a definitive document to adhere to. Earlier versions
   might have accepted source code that is no longer C++. This means that
   code which might have `worked' in a previous version, is now rejected.
   You should update your code to be C++.

   You  should  try  to  use  the  latest  stable  release of the GNU C++
   compiler.

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

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

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

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

  ABI bugs

   3.0  had a new ABI, which affected class layout, function mangling and
   calling  conventions. We had intended it to be complete, unfortunately
   some  issues came to light, too late to fix in the 3.0 series. The ABI
   should  not change in dot releases, so we addressed most issues in GCC
   3.1.

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

  Non-bugs

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

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

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

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

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

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

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

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

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

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

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

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

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

   Templates, scoping, and digraphs.
          If  you have a class in global namespace, say named X, and want
          to  give  it  as  a  template argument to some other class, say
          std::vector,   then  this  here  fails  with  a  parser  error:
          std::vector<::X>.

          The  reason  is that the standard mandates that the sequence <:
          is  treated  as  if  it  were  the token [, and the parser then
          reports a parse error before the character : (by which it means
          the  second  colon).  There  are  several  such combinations of
          characters, and they are called digraphs.

          The  simplest  way to avoid this is to write std::vector< ::X>,
          i.e.  place  a  space between the opening angle bracket and the
          scope operator.

  Missing features

   We know some things are missing from G++.

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

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

  Parse errors for "simple" code

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

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

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

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

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

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

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

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

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

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

  Optimization at -O3 takes a very long time

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

References

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