source: trunk/third/gcc/BUGS @ 18474

Revision 18474, 25.5 KB checked in by ghudson, 22 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r18473, which included commits to RCS files with non-trunk default branches.
Line 
1
2                                   GCC Bugs
3
4   The   latest   version   of  this  document  is  always  available  at
5   [1]http://www.gnu.org/software/gcc/bugs.html.
6     _________________________________________________________________
7
8Table of Contents
9
10     * [2]Reporting Bugs
11          + [3]What we need
12          + [4]What we DON'T want
13          + [5]Where to post it
14          + [6]Detailed bug reporting instructions
15          + [7]Detailed bug reporting instructions for GNAT
16     * [8]Managing Bugs (GNATS and the test-suite)
17     * [9]Frequently Reported Bugs in GCC
18          + [10]General
19          + [11]Fortran
20          + [12]C
21          + [13]C++
22               o [14]Common problems updating from G++ 2.95 to G++ 3.0
23               o [15]Non-bugs
24               o [16]Missing features
25               o [17]Parse errors for "simple" code
26               o [18]Optimization at -O3 takes a very long time
27     _________________________________________________________________
28
29                                Reporting Bugs
30
31   Our  preferred  way  of  receiving  bugs  is via the [19]GCC GNATS bug
32   reporting system.
33
34   Before  you report a bug, please check the [20]list of well-known bugs
35   and,  if  possible  in any way, try a current development snapshot. If
36   you  want  to report a bug with versions of GCC before 3.1 we strongly
37   recommend upgrading to the current release first.
38
39   Before  reporting  that  GCC  compiles  your  code incorrectly, please
40   compile  it  with  gcc -Wall and see whether this shows anything wrong
41   with your code that could be the cause instead of a bug in GCC.
42
43Summarized bug reporting instructions
44
45   After  this  summary, you'll find detailed bug reporting instructions,
46   that  explain  how to obtain some of the information requested in this
47   summary.
48
49  What we need
50
51   Please  include  in  your  bug  report all of the following items, the
52   first three of which can be obtained from the output of gcc -v:
53     * the exact version of GCC;
54     * the system type;
55     * the options given when GCC was configured/built;
56     * the complete command line that triggers the bug;
57     * the compiler output (error messages, warnings, etc.); and
58     * the  preprocessed  file (*.i*) that triggers the bug, generated by
59       adding -save-temps to the complete compilation command, or, in the
60       case  of  a  bug  report for the GNAT front end, a complete set of
61       source files (see below).
62
63  What we do not want
64
65     * A source file that #includes header files that are left out of the
66       bug report (see above)
67     * That source file and a collection of header files.
68     * An  attached archive (tar, zip, shar, whatever) containing all (or
69       some :-) of the above.
70     * A  code snippet that won't cause the compiler to produce the exact
71       output  mentioned  in  the bug report (e.g., a snippet with just a
72       few  lines  around  the one that apparently triggers the bug, with
73       some   pieces   replaced  with  ellipses  or  comments  for  extra
74       obfuscation :-)
75     * The  location  (URL) of the package that failed to build (we won't
76       download it, anyway, since you've already given us what we need to
77       duplicate the bug, haven't you? :-)
78     * An  error  that  occurs  only  some of the times a certain file is
79       compiled,  such that retrying a sufficient number of times results
80       in  a  successful  compilation;  this  is  a symptom of a hardware
81       problem, not of a compiler bug (sorry)
82     * E-mail  messages that complement previous, incomplete bug reports.
83       Post  a  new, self-contained, full bug report instead, if possible
84       as a follow-up to the original bug report
85     * Assembly  files  (*.s)  produced  by  the  compiler, or any binary
86       files, such as object files, executables or core files
87     * Duplicate  bug  reports,  or  reports of bugs already fixed in the
88       development tree, especially those that have already been reported
89       as fixed last week :-)
90     * Bugs  in  the  assembler,  the  linker or the C library. These are
91       separate  projects,  with separate mailing lists and different bug
92       reporting procedures
93     * Bugs  in  releases  or  snapshots  of  GCC  not  issued by the GNU
94       Project. Report them to whoever provided you with the release
95     * Questions  about  the  correctness  or  the  expected  behavior of
96       certain constructs that are not GCC extensions. Ask them in forums
97       dedicated to the discussion of the programming language
98
99  Where to post it
100
101   Please  submit  your  bug  report  directly  to  the [21]GCC GNATS bug
102   database.  Only  if  this  is  not  possible,  mail all information to
103   [22]bug-gcc@gnu.org or [23]gcc-bugs@gcc.gnu.org.
104
105   The  GCC  lists  have message size limits (200 kbytes) and bug reports
106   over  those  limits  will  currently be bounced. If your bug is larger
107   than that, please post it using the [24]GCC GNATS bug database.
108
109Detailed bug reporting instructions
110
111   Please  refer to the [25]next section when reporting bugs in GNAT, the
112   Ada compiler.
113
114   In  general, all the information we need can be obtained by collecting
115   the  command  line  below,  as well as its output and the preprocessed
116   file it generates.
117
118     gcc -v -save-temps all-your-options source-file
119
120   Typically  the  preprocessed  file (extension .i for C or .ii for C++)
121   will  be  large, so please compress the resulting file with one of the
122   popular  compression programs such as bzip2, gzip, zip or compress (in
123   decreasing  order  of  preference).  Use  maximum  compression (-9) if
124   available.  Please  include the compressed preprocessor output in your
125   bug  report, even if the source code is freely available elsewhere; it
126   makes the job of our volunteer testers much easier.
127
128   The  only  excuses  to not send us the preprocessed sources are (i) if
129   you've  found a bug in the preprocessor, or (ii) if you've reduced the
130   testcase  to  a small file that doesn't include any other file. If you
131   can't  post the preprocessed sources because they're proprietary code,
132   then try to create a small file that triggers the same problem.
133
134   Since  we're  supposed  to  be  able  to re-create the assembly output
135   (extension  .s),  you usually should not include it in the bug report,
136   although  you  may want to post parts of it to point out assembly code
137   you consider to be wrong.
138
139   Whether to use MIME attachments or uuencode is up to you. In any case,
140   make  sure  the compiler command line, version and error output are in
141   plain text, so that we don't have to decode the bug report in order to
142   tell  who  should  take  care  of  it. A meaningful subject indicating
143   language and platform also helps.
144
145   Please  avoid  posting  an archive (.tar, .shar or .zip); we generally
146   need  just a single file to reproduce the bug (the .i/.ii preprocessed
147   file),  and,  by  storing  it  in  an  archive, you're just making our
148   volunteers'  jobs  harder. Only when your bug report requires multiple
149   source  files to be reproduced should you use an archive. In any case,
150   make  sure  the  compiler version, error message, etc, are included in
151   the  body  of  your  bug  report  as  plain  text,  even if needlessly
152   duplicated as part of an archive.
153
154   If  you  fail  to  supply  enough  information  for a bug report to be
155   reproduced,   someone   will  probably  ask  you  to  post  additional
156   information  (or just ignore your bug report, if they're in a bad day,
157   so  try to get it right on the first posting :-). In this case, please
158   post the additional information to the bug reporting mailing list, not
159   just  to  the  person  who requested it, unless explicitly told so. If
160   possible, please include in this follow-up all the information you had
161   supplied  in  the  incomplete  bug  report (including the preprocessor
162   output), so that the new bug report is self-contained.
163
164Detailed bug reporting instructions for GNAT
165
166   See  the  [26]previous  section for bug reporting instructions for GCC
167   language implementations other than Ada.
168
169   Bug  reports  have  to  contain  at least the following information in
170   order to be useful:
171     * the exact version of GCC, as shown by "gcc -v";
172     * the system type;
173     * the options when GCC was configured/built;
174     * the  exact  command  line passed to the gcc program triggering the
175       bug  (not  just  the flags passed to gnatmake, but gnatmake prints
176       the parameters it passed to gcc)
177     * a collection of source files for reproducing the bug, preferably a
178       minimal set (see below);
179     * a description of the expected behavior;
180     * a description of actual behavior.
181
182   If  your  code  depends  on  additional  source files (usually package
183   specifications), submit the source code for these compilation units in
184   a  single  file that is acceptable input to gnatchop, i.e. contains no
185   non-Ada  text. If the compilation terminated normally, you can usually
186   obtain a list of dependencies using the "gnatls -d main_unit" command,
187   where  main_unit  is the file name of the main compilation unit (which
188   is also passed to gcc).
189
190   If  you  report  a  bug  which causes the compiler to print a bug box,
191   include that bug box in your report, and do not forget to send all the
192   source files listed after the bug box along with your report.
193
194   If  you  use gnatprep, be sure to send in preprocessed sources (unless
195   you have to report a bug in gnatprep).
196
197   When  you  have  checked that your report meets these criteria, please
198   submit  it  accoding  to  our  [27]generic instructions. (If you use a
199   mailing  list  for  reporting,  please  include  an "[Ada]" tag in the
200   subject.)
201
202                   Managing Bugs (GNATS and the test-suite)
203
204   This   section   contains   information   mostly   intended   for  GCC
205   contributors.
206
207   If you find a bug, but you are not fixing it (yet):
208    1. Create a (minimal) test-case.
209    2. Add  the  test-case  to our test-suite, marking it as XFAIL unless
210       the bug is a regression.
211    3. Add a bug report referencing the test-case to GNATS.
212
213   If you fix a bug for which there is already a GNATS entry:
214    1. Remove the XFAIL on the test-case.
215    2. Close the bug report in GNATS.
216
217   If you find a bug, and you are fixing it right then:
218    1. Create a (minimal) test-case.
219    2. Add the test-case to our test-suite, marking it as PASS.
220    3. Check in your fixes.
221     _________________________________________________________________
222
223                        Frequently Reported Bugs in GCC
224
225Fortran
226
227   Fortran  bugs  are documented in the G77 manual rather than explicitly
228   listed  here.  Please see [28]Known Causes of Trouble with GNU Fortran
229   in the G77 manual.
230     _________________________________________________________________
231
232C
233
234   The  following  are not bugs in the C compiler, but are reported often
235   enough to warrant a mention here.
236
237   Cannot initialize a static variable with stdin.
238          This  has  nothing to do with GCC, but people ask us about it a
239          lot. Code like this:
240
241#include <stdio.h>
242
243FILE *yyin = stdin;
244
245          will not compile with GNU libc (GNU/Linux libc6), because stdin
246          is  not  a  constant.  This  was  done deliberately, to make it
247          easier  to  maintain  binary  compatibility  when the type FILE
248          needs  to  be  changed.  It  is  surprising  for people used to
249          traditional  Unix  C  libraries,  but  it is permitted by the C
250          standard.
251
252          This  construct  commonly  occurs  in  code  generated  by  old
253          versions  of  lex  or yacc. We suggest you try regenerating the
254          parser  with  a current version of flex or bison, respectively.
255          In   your  own  code,  the  appropriate  fix  is  to  move  the
256          initialization to the beginning of main.
257
258          There  is  a  common  misconception that the GCC developers are
259          responsible  for  GNU  libc.  These  are  in  fact two entirely
260          separate  projects; please check the [29]GNU libc web pages for
261          details.
262
263   Cannot use preprocessor directive in macro arguments.
264          Let me guess... you wrote code that looks something like this:
265
266  memcpy(dest, src,
267#ifdef PLATFORM1
268         12
269#else
270         24
271#endif
272        );
273
274          and you got a whole pile of error messages:
275
276     test.c:11:  warning:  preprocessing directive not recognized within
277     macro arg
278     test.c:11:  warning:  preprocessing directive not recognized within
279     macro arg
280     test.c:11:  warning:  preprocessing directive not recognized within
281     macro arg
282     test.c: In function `foo':
283     test.c:6: undefined or invalid # directive
284     test.c:8: undefined or invalid # directive
285     test.c:9: parse error before `24'
286     test.c:10: undefined or invalid # directive
287     test.c:11: parse error before `#'
288
289          Update: As of GCC 3.2 this kind of construct is always accepted
290          and  CPP  will  probably do what you expect, but see the manual
291          for detailed semantics.
292
293          However,  versions of GCC prior to 3.2 did not allow you to put
294          #ifdef  (or  any  other  directive)  inside  the arguments of a
295          macro.  Your C library's <string.h> happens to define memcpy as
296          a  macro  -  this  is  perfectly legitimate. The code therefore
297          would not compile.
298
299          This  kind  of code is not portable. It is "undefined behavior"
300          according  to  the  C  standard; that means different compilers
301          will  do  different  things  with  it. It is always possible to
302          rewrite  code  which uses conditionals inside macros so that it
303          doesn't. You could write the above example
304
305#ifdef PLATFORM1
306   memcpy(dest, src, 12);
307#else
308   memcpy(dest, src, 24);
309#endif
310
311          This  is  a bit more typing, but I personally think it's better
312          style in addition to being more portable.
313
314          In  recent  versions  of  glibc,  printf is among the functions
315          which are implemented as macros.
316     _________________________________________________________________
317
318C++
319
320   This  is the list of bugs (and non-bugs) in g++ (aka GNU C++) that are
321   reported  very  often, but not yet fixed. While it is certainly better
322   to  fix  bugs  instead  of  documenting them, this document might save
323   people  the  effort  of  writing  a bug report when the bug is already
324   well-known. [30]How to report bugs tells you how to report a bug.
325
326   There  are many reasons why reported bugs don't get fixed. It might be
327   difficult  to  fix,  or  fixing  it  might break compatibility. Often,
328   reports  get  a  low  priority  when there is a simple work-around. In
329   particular, bugs caused by invalid C++ code have a simple work-around,
330   fix  the  code. Now that there is an agreed ISO/ANSI standard for C++,
331   the  compiler has a definitive document to adhere to. Earlier versions
332   might have accepted source code that is no longer C++. This means that
333   code which might have `worked' in a previous version, is now rejected.
334   You should update your code to be C++.
335
336   You  should  try  to  use  the  latest  stable  release of the GNU C++
337   compiler.
338
339  Common problems updating from G++ 2.95 to G++ 3.0
340
341   G++  3.0  conforms  much  closer to the ISO C++ standard (available at
342   [31]http://www.ncits.org/cplusplus.htm).
343
344   We  have  also implemented some of the core and library defect reports
345   (available at
346   [32]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html      &
347   [33]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
348   respectively).
349     * The  ABI  has  changed. This means that both class layout and name
350       mangling  is  different.  You must recompile all c++ libraries (if
351       you don't you will get link errors).
352     * The  standard  library is much more conformant, and uses the std::
353       namespace.
354     * std:: is now a real namespace, not an alias for ::.
355     * The standard header files for the c library don't end with .h, but
356       begin with c (i.e. <cstdlib> rather than <stdlib.h>). The .h names
357       are still available, but are deprecated.
358     * <strstream> is deprecated, use <sstream> instead.
359     * streambuf::seekoff  &  streambuf::seekpos are private, instead use
360       streambuf::pubseekoff & streambuf::pubseekpos respectively.
361     * If std::operator << (std::ostream &, long long) doesn't exist, you
362       need to recompile libstdc++ with --enable-long-long.
363
364   This  means  you  may  get lots of errors about things like strcmp not
365   being found. You've most likely forgotton to tell the compiler to look
366   in the std:: namespace. There are several ways to do this,
367     * Say,  std::strcmp  at  the  call. This is the most explicit way of
368       saying what you mean.
369     * Say,  using  std::strcmp; somewhere before the call. You will need
370       to  do  this  for  each  function or type you wish to use from the
371       standard library.
372     * Say,  using  namespace std; somewhere before the call. This is the
373       quick-but-dirty  fix. This brings the whole of the std:: namespace
374       into scope. Never do this in a header file, as you will be forcing
375       users of your header file to do the same.
376
377  ABI bugs
378
379   3.0  had a new ABI, which affected class layout, function mangling and
380   calling  conventions. We had intended it to be complete, unfortunately
381   some  issues came to light, too late to fix in the 3.0 series. The ABI
382   should  not change in dot releases, so we addressed most issues in GCC
383   3.1.
384
385   Covariant return types
386          We  do  not  implement  non-trivial  covariant returns. We also
387          generate   incorrect   virtual   function  tables  for  trivial
388          covariance.  Although  trivial  covariance  will  work,  it  is
389          incompatible with the ABI. GNATS PR 3706 tracks this problem.
390
391  Non-bugs
392
393   Here are some features that have been reported as bugs, but are not.
394
395   Nested classes can access private types of the containing class.
396          G++  now implements type access control on member types. Defect
397          report  45  clarifies  that  nested  classes are members of the
398          class  they are nested in, and so are granted access to private
399          members of that class.
400
401   Classes in exception specifiers must be complete types.
402          [15.4]/1  tells you that you cannot have an incomplete type, or
403          pointer  to  incomplete  (other than cv void *) in an exception
404          specification.
405
406   G++ emits two copies of constructors and destructors.
407          In   general   there  are  three  types  of  constructors  (and
408          destructors).
409
410         1. The complete object constructor/destructor.
411         2. The base object constructor/destructor.
412         3. The allocating destructor/deallocating destructor.
413
414          The  first  two  are  different,  when virtual base classes are
415          involved. In some cases we can do better, and this is logged in
416          GNATS.
417
418   Exceptions don't work in multithreaded applications.
419          You  need  to  rebuild g++ and libstdc++ with --enable-threads.
420          Remember,  c++ exceptions are not like hardware interrupts. You
421          cannot  throw  an  exception  in  one  thread  and  catch it in
422          another.  You  cannot throw an exception from a signal handler,
423          and catch it in the main thread.
424
425   Global destructors are not run in the correct order.
426          Global  destructors should be run in the reverse order of their
427          constructors  completing. In most cases this is the same as the
428          reverse  order  of  constructors  starting, but sometimes it is
429          different,  and that is important. You need to compile and link
430          your  programs  with  --use-cxa-atexit. We have not turned this
431          switch  on  by  default,  as  it  requires  a cxa aware runtime
432          library (libc, glibc, or equivalent).
433
434   Problems with floating point computations.
435          In  a  number  of  cases, GCC appears to perform floating point
436          computations incorrectly. For example, the program
437
438     #include <iostream>
439     int main() {
440     double min = 0.0;
441     double max = 0.5;
442     double width = 0.01;
443     std::cout << (int)(((max - min) / width) - 1) << std::endl;
444     }
445
446          might  print 50 on some systems and optimization levels, and 51
447          on others.
448
449          The  is  the  result of rounding: The computer cannot represent
450          all real numbers exactly, so it has to use approximations. When
451          computing  with  approximation,  the computer needs to round to
452          the nearest representable number.
453
454          This  is  not a bug in the compiler, but an inherent limitation
455          of  the float and double types. Please study [34]this paper for
456          more information.
457
458   Templates, scoping, and digraphs.
459          If  you have a class in global namespace, say named X, and want
460          to  give  it  as  a  template argument to some other class, say
461          std::vector,   then  this  here  fails  with  a  parser  error:
462          std::vector<::X>.
463
464          The  reason  is that the standard mandates that the sequence <:
465          is  treated  as  if  it  were  the token [, and the parser then
466          reports a parse error before the character : (by which it means
467          the  second  colon).  There  are  several  such combinations of
468          characters, and they are called digraphs.
469
470          The  simplest  way to avoid this is to write std::vector< ::X>,
471          i.e.  place  a  space between the opening angle bracket and the
472          scope operator.
473
474  Missing features
475
476   We know some things are missing from G++.
477
478   The export keyword is not implemented.
479          Most  C++ compilers (G++ included) do not yet implement export,
480          which   is  necessary  for  separate  compilation  of  template
481          declarations   and  definitions.  Without  export,  a  template
482          definition  must be in scope to be used. The obvious workaround
483          is  simply  to  place  all  definitions  in  the header itself.
484          Alternatively,   the   compilation   unit  containing  template
485          definitions may be included from the header.
486
487   Two stage lookup in templates is not implemented.
488          [14.6] specifies how names are looked up inside a template. G++
489          does  not  do  this correctly, but for most templates this will
490          not be noticeable.
491
492  Parse errors for "simple" code
493
494   Up  to and including GCC 3.0, the compiler will give "parse error" for
495   seemingly simple code, such as
496struct A{
497  A();
498  A(int);
499  void func();
500};
501
502struct B{
503  B(A);
504  B(A,A);
505  void func();
506};
507
508void foo(){
509  B b(A(),A(1));     //Variable b, initialized with two temporaries
510  B(A(2)).func();    //B temporary, initialized with A temporary
511}
512
513   The  problem  is  that  GCC  starts to parse the declaration of b as a
514   function  b returning B, taking a function returning A as an argument.
515   When  it sees the 1, it is too late. The work-around in these cases is
516   to add additional parentheses around the expressions that are mistaken
517   as declarations:
518  (B(A(2))).func();
519
520   Sometimes,  even  that  is  not enough; to show the compiler that this
521   should be really an expression, a comma operator with a dummy argument
522   can be used:
523  B b((0,A()),A(1));
524
525   Another example is the parse error for the return statement in
526struct A{};
527
528struct B{
529  A a;
530  A f1(bool);
531};
532
533A B::f1(bool b)
534{
535  if (b)
536    return (A());
537  return a;
538}
539
540   The  problem is that the compiler interprets A() as a function (taking
541   no  arguments,  returning  A),  and  (A())  as a cast - with a missing
542   expression,  hence  the  parse  error.  The work-around is to omit the
543   parentheses:
544  if (b)
545    return A();
546
547   This  problem  occurs  in  a  number of variants; in throw statements,
548   people  also frequently put the object in parentheses. The exact error
549   also  somewhat  varies  with  the  compiler  version. The work-arounds
550   proposed  do not change the semantics of the program at all; they make
551   them perhaps less readable.
552
553  Optimization at -O3 takes a very long time
554
555   At  -O3, all functions are candidates for inlining. The heuristic used
556   has some deficiencies which show up when allowed such freedom. This is
557   g++ specific, as it has an earlier inliner than gcc.
558
559References
560
561   1. http://www.gnu.org/software/gcc/bugs.html
562   2. http://gcc.gnu.org/bugs.html#report
563   3. http://gcc.gnu.org/bugs.html#need
564   4. http://gcc.gnu.org/bugs.html#dontwant
565   5. http://gcc.gnu.org/bugs.html#where
566   6. http://gcc.gnu.org/bugs.html#detailed
567   7. http://gcc.gnu.org/bugs.html#gnat
568   8. http://gcc.gnu.org/bugs.html#manage
569   9. http://gcc.gnu.org/bugs.html#known
570  10. http://gcc.gnu.org/bugs.html#general
571  11. http://gcc.gnu.org/bugs.html#fortran
572  12. http://gcc.gnu.org/bugs.html#c
573  13. http://gcc.gnu.org/bugs.html#cplusplus
574  14. http://gcc.gnu.org/bugs.html#updating
575  15. http://gcc.gnu.org/bugs.html#nonbugs
576  16. http://gcc.gnu.org/bugs.html#missing
577  17. http://gcc.gnu.org/bugs.html#parsing
578  18. http://gcc.gnu.org/bugs.html#-O3
579  19. http://gcc.gnu.org/gnats.html
580  20. http://gcc.gnu.org/bugs.html#known
581  21. http://gcc.gnu.org/gnats.html
582  22. mailto:bug-gcc@gnu.org
583  23. mailto:gcc-bugs@gcc.gnu.org
584  24. http://gcc.gnu.org/gnats.html
585  25. http://gcc.gnu.org/bugs.html#gnat
586  26. http://gcc.gnu.org/bugs.html#detailed
587  27. http://gcc.gnu.org/bugs.html#where
588  28. http://gcc.gnu.org/onlinedocs/g77/Trouble.html
589  29. http://www.gnu.org/software/glibc/
590  30. http://gcc.gnu.org/bugs.html#report
591  31. http://www.ncits.org/cplusplus.htm
592  32. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html
593  33. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html
594  34. http://www.validlab.com/goldberg/paper.ps
Note: See TracBrowser for help on using the repository browser.