OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-old/] [gcc-4.2.2/] [BUGS] - Blame information for rev 819

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 38 julius
 
2
                                   GCC Bugs
3
 
4
   The   latest   version   of  this  document  is  always  available  at
5
   [1]http://gcc.gnu.org/bugs.html.
6
     _________________________________________________________________
7
 
8
Table 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]Detailed bug reporting instructions when using a precompiled
17
            header
18
     * [9]Frequently Reported Bugs in GCC
19
          + [10]C++
20
               o [11]Missing features
21
               o [12]Bugs fixed in the 3.4 series
22
          + [13]Fortran
23
     * [14]Non-bugs
24
          + [15]General
25
          + [16]C
26
          + [17]C++
27
               o [18]Common problems when upgrading the compiler
28
     _________________________________________________________________
29
 
30
                                Reporting Bugs
31
 
32
   The main purpose of a bug report is to enable us to fix the bug. The most
33
   important prerequisite for this is that the report must be complete and
34
   self-contained.
35
 
36
   Before you report a bug, please check the [19]list of well-known bugs and,
37
   if possible, try a current development snapshot. If you want to report a bug
38
   with versions of GCC before 3.4 we strongly recommend upgrading to the
39
   current release first.
40
 
41
   Before reporting that GCC compiles your code incorrectly, please compile it
42
   with gcc -Wall and see whether this shows anything wrong with your code that
43
   could be the cause instead of a bug in GCC.
44
 
45
Summarized bug reporting instructions
46
 
47
   After this summary, you'll find detailed bug reporting instructions, that
48
   explain how to obtain some of the information requested in this summary.
49
 
50
  What we need
51
 
52
   Please include in your bug report all of the following items, the first
53
   three of which can be obtained from the output of gcc -v:
54
     * the exact version of GCC;
55
     * the system type;
56
     * the options given when GCC was configured/built;
57
     * the complete command line that triggers the bug;
58
     * the compiler output (error messages, warnings, etc.); and
59
     * the preprocessed file (*.i*) that triggers the bug, generated by adding
60
       -save-temps to the complete compilation command, or, in the case of a
61
       bug report for the GNAT front end, a complete set of source files (see
62
       below).
63
 
64
  What we do not want
65
 
66
     * A source file that #includes header files that are left out of the bug
67
       report (see above)
68
     * That source file and a collection of header files.
69
     * An attached archive (tar, zip, shar, whatever) containing all (or some
70
       :-) of the above.
71
     * A code snippet that won't cause the compiler to produce the exact output
72
       mentioned in the bug report (e.g., a snippet with just a few lines
73
       around  the one that apparently triggers the bug, with some pieces
74
       replaced with ellipses or comments for extra 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 compiled,
79
       such that retrying a sufficient number of times results in a successful
80
       compilation; this is a symptom of a hardware problem, not of a compiler
81
       bug (sorry)
82
     * Assembly files (*.s) produced by the compiler, or any binary files, such
83
       as object files, executables, core files, or precompiled header files
84
     * Duplicate  bug  reports,  or  reports of bugs already fixed in the
85
       development tree, especially those that have already been reported as
86
       fixed last week :-)
87
     * Bugs in the assembler, the linker or the C library. These are separate
88
       projects,  with separate mailing lists and different bug reporting
89
       procedures
90
     * Bugs in releases or snapshots of GCC not issued by the GNU Project.
91
       Report them to whoever provided you with the release
92
     * Questions about the correctness or the expected behavior of certain
93
       constructs that are not GCC extensions. Ask them in forums dedicated to
94
       the discussion of the programming language
95
 
96
  Where to post it
97
 
98
   Please  submit  your  bug report directly to the [20]GCC bug database.
99
   Alternatively, you can use the gccbug script that mails your bug report to
100
   the bug database.
101
   Only  if  all  this  is absolutely impossible, mail all information to
102
   [21]gcc-bugs@gcc.gnu.org.
103
 
104
Detailed bug reporting instructions
105
 
106
   Please refer to the [22]next section when reporting bugs in GNAT, the Ada
107
   compiler, or to the [23]one after that when reporting bugs that appear when
108
   using a precompiled header.
109
 
110
   In general, all the information we need can be obtained by collecting the
111
   command line below, as well as its output and the preprocessed file it
112
   generates.
113
 
114
     gcc -v -save-temps all-your-options source-file
115
 
116
   The only excuses to not send us the preprocessed sources are (i) if you've
117
   found a bug in the preprocessor, (ii) if you've reduced the testcase to a
118
   small file that doesn't include any other file or (iii) if the bug appears
119
   only when using precompiled headers. If you can't post the preprocessed
120
   sources because they're proprietary code, then try to create a small file
121
   that triggers the same problem.
122
 
123
   Since we're supposed to be able to re-create the assembly output (extension
124
   .s), you usually should not include it in the bug report, although you may
125
   want to post parts of it to point out assembly code you consider to be
126
   wrong.
127
 
128
   Please avoid posting an archive (.tar, .shar or .zip); we generally need
129
   just a single file to reproduce the bug (the .i/.ii/.f preprocessed file),
130
   and, by storing it in an archive, you're just making our volunteers' jobs
131
   harder. Only when your bug report requires multiple source files to be
132
   reproduced should you use an archive. This is, for example, the case if you
133
   are using INCLUDE directives in Fortran code, which are not processed by the
134
   preprocessor, but the compiler. In that case, we need the main file and all
135
   INCLUDEd files. In any case, make sure the compiler version, error message,
136
   etc, are included in the body of your bug report as plain text, even if
137
   needlessly duplicated as part of an archive.
138
 
139
Detailed bug reporting instructions for GNAT
140
 
141
   See the [24]previous section for bug reporting instructions for GCC language
142
   implementations other than Ada.
143
 
144
   Bug reports have to contain at least the following information in order to
145
   be useful:
146
     * the exact version of GCC, as shown by "gcc -v";
147
     * the system type;
148
     * the options when GCC was configured/built;
149
     * the exact command line passed to the gcc program triggering the bug (not
150
       just the flags passed to gnatmake, but gnatmake prints the parameters it
151
       passed to gcc)
152
     * a collection of source files for reproducing the bug, preferably a
153
       minimal set (see below);
154
     * a description of the expected behavior;
155
     * a description of actual behavior.
156
 
157
   If  your  code  depends  on  additional  source files (usually package
158
   specifications), submit the source code for these compilation units in a
159
   single file that is acceptable input to gnatchop, i.e. contains no non-Ada
160
   text. If the compilation terminated normally, you can usually obtain a list
161
   of dependencies using the "gnatls -d main_unit" command, where main_unit is
162
   the file name of the main compilation unit (which is also passed to gcc).
163
 
164
   If you report a bug which causes the compiler to print a bug box, include
165
   that bug box in your report, and do not forget to send all the source files
166
   listed after the bug box along with your report.
167
 
168
   If you use gnatprep, be sure to send in preprocessed sources (unless you
169
   have to report a bug in gnatprep).
170
 
171
   When you have checked that your report meets these criteria, please submit
172
   it according to our [25]generic instructions. (If you use a mailing list for
173
   reporting, please include an "[Ada]" tag in the subject.)
174
 
175
Detailed bug reporting instructions when using a precompiled header
176
 
177
   If you're encountering a bug when using a precompiled header, the first
178
   thing to do is to delete the precompiled header, and try running the same
179
   GCC command again. If the bug happens again, the bug doesn't really involve
180
   precompiled headers, please report it without using them by following the
181
   instructions [26]above.
182
 
183
   If you've found a bug while building a precompiled header (for instance, the
184
   compiler crashes), follow the usual instructions [27]above.
185
 
186
   If you've found a real precompiled header bug, what we'll need to reproduce
187
   it is the sources to build the precompiled header (as a single .i file), the
188
   source file that uses the precompiled header, any other headers that source
189
   file includes, and the command lines that you used to build the precompiled
190
   header and to use it.
191
 
192
   Please don't send us the actual precompiled header. It is likely to be very
193
   large and we can't use it to reproduce the problem.
194
     _________________________________________________________________
195
 
196
                        Frequently Reported Bugs in GCC
197
 
198
   This is a list of bugs in GCC that are reported very often, but not yet
199
   fixed. While it is certainly better to fix bugs instead of documenting them,
200
   this document might save people the effort of writing a bug report when the
201
   bug is already well-known.
202
 
203
   There are many reasons why a reported bug doesn't get fixed. It might be
204
   difficult to fix, or fixing it might break compatibility. Often, reports get
205
   a low priority when there is a simple work-around. In particular, bugs
206
   caused by invalid code have a simple work-around: fix the code.
207
     _________________________________________________________________
208
 
209
C++
210
 
211
  Missing features
212
 
213
   The export keyword is not implemented.
214
          Most C++ compilers (G++ included) do not yet implement export, which
215
          is necessary for separate compilation of template declarations and
216
          definitions. Without export, a template definition must be in scope
217
          to be used. The obvious workaround is simply to place all definitions
218
          in the header itself. Alternatively, the compilation unit containing
219
          template definitions may be included from the header.
220
 
221
  Bugs fixed in the 3.4 series
222
 
223
   The following bugs are present up to (and including) GCC 3.3.x. They have
224
   been fixed in 3.4.0.
225
 
226
   Two-stage name-lookup.
227
          GCC did not implement two-stage name-lookup (also see [28]below).
228
 
229
   Covariant return types.
230
          GCC did not implement non-trivial covariant returns.
231
 
232
   Parse errors for "simple" code.
233
          GCC gave parse errors for seemingly simple code, such as
234
 
235
struct A
236
{
237
  A();
238
  A(int);
239
};
240
 
241
struct B
242
{
243
  B(A);
244
  B(A,A);
245
  void foo();
246
};
247
 
248
A bar()
249
{
250
  B b(A(),A(1));  // Variable b, initialized with two temporaries
251
  B(A(2)).foo();  // B temporary, initialized with A temporary
252
  return (A());   // return A temporary
253
}
254
 
255
          Although being valid code, each of the three lines with a comment was
256
          rejected  by  GCC. The work-arounds for older compiler versions
257
          proposed below do not change the semantics of the programs at all.
258
 
259
          The problem in the first case was that GCC started to parse the
260
          declaration  of  b as a function called b returning B, taking a
261
          function returning A as an argument. When it encountered the 1, it
262
          was too late. To show the compiler that this should be really an
263
          expression, a comma operator with a dummy argument could be used:
264
 
265
B b((0,A()),A(1));
266
 
267
          The work-around for simpler cases like the second one was to add
268
          additional parentheses around the expressions that were mistaken as
269
          declarations:
270
 
271
(B(A(2))).foo();
272
 
273
          In the third case, however, additional parentheses were causing the
274
          problems: The compiler interpreted A() as a function (taking no
275
          arguments, returning A), and (A()) as a cast lacking an expression to
276
          be casted, hence the parse error. The work-around was to omit the
277
          parentheses:
278
 
279
return A();
280
 
281
          This problem occurred in a number of variants; in throw statements,
282
          people also frequently put the object in parentheses.
283
     _________________________________________________________________
284
 
285
Fortran
286
 
287
   G77 bugs are documented in the G77 manual rather than explicitly listed
288
   here. Please see [29]Known Causes of Trouble with GNU Fortran in the G77
289
   manual.
290
     _________________________________________________________________
291
 
292
                                   Non-bugs
293
 
294
   The  following are not actually bugs, but are reported often enough to
295
   warrant a mention here.
296
 
297
   It is not always a bug in the compiler, if code which "worked" in a previous
298
   version, is now rejected. Earlier versions of GCC sometimes were less picky
299
   about standard conformance and accepted invalid source code. In addition,
300
   programming languages themselves change, rendering code invalid that used to
301
   be conforming (this holds especially for C++). In either case, you should
302
   update your code to match recent language standards.
303
     _________________________________________________________________
304
 
305
General
306
 
307
   Problems with floating point numbers - the [30]most often reported non-bug.
308
          In  a  number  of  cases, GCC appears to perform floating point
309
          computations incorrectly. For example, the C++ program
310
 
311
#include 
312
 
313
int main()
314
{
315
  double a = 0.5;
316
  double b = 0.01;
317
  std::cout << (int)(a / b) << std::endl;
318
  return 0;
319
}
320
 
321
          might print 50 on some systems and optimization levels, and 49 on
322
          others.
323
 
324
          This is the result of rounding: The computer cannot represent all
325
          real numbers exactly, so it has to use approximations. When computing
326
          with  approximation, the computer needs to round to the nearest
327
          representable number.
328
 
329
          This is not a bug in the compiler, but an inherent limitation of the
330
          floating  point  types.  Please  study  [31]this paper for more
331
          information.
332
     _________________________________________________________________
333
 
334
C
335
 
336
   Increment/decrement operator (++/--) not working as expected - a [32]problem
337
          with many variations.
338
          The following expressions have unpredictable results:
339
 
340
x[i]=++i
341
foo(i,++i)
342
i*(++i)                 /* special case with foo=="operator*" */
343
std::cout << i << ++i   /* foo(foo(std::cout,i),++i)          */
344
 
345
          since the i without increment can be evaluated before or after ++i.
346
 
347
          The  C  and C++ standards have the notion of "sequence points".
348
          Everything that happens between two sequence points happens in an
349
          unspecified order, but it has to happen after the first and before
350
          the second sequence point. The end of a statement and a function call
351
          are examples for sequence points, whereas assignments and the comma
352
          between function arguments are not.
353
 
354
          Modifying a value twice between two sequence points as shown in the
355
          following examples is even worse:
356
 
357
i=++i
358
foo(++i,++i)
359
(++i)*(++i)               /* special case with foo=="operator*" */
360
std::cout << ++i << ++i   /* foo(foo(std::cout,++i),++i)        */
361
 
362
          This leads to undefined behavior (i.e. the compiler can do anything).
363
 
364
   Casting does not work as expected when optimization is turned on.
365
          This is often caused by a violation of aliasing rules, which are part
366
          of the ISO C standard. These rules say that a program is invalid if
367
          you try to access a variable through a pointer of an incompatible
368
          type. This is happening in the following example where a short is
369
          accessed through a pointer to integer (the code assumes 16-bit shorts
370
          and 32-bit ints):
371
 
372
#include 
373
 
374
int main()
375
{
376
  short a[2];
377
 
378
  a[0]=0x1111;
379
  a[1]=0x1111;
380
 
381
  *(int *)a = 0x22222222; /* violation of aliasing rules */
382
 
383
  printf("%x %x\n", a[0], a[1]);
384
  return 0;
385
}
386
 
387
          The aliasing rules were designed to allow compilers more aggressive
388
          optimization. Basically, a compiler can assume that all changes to
389
          variables happen through pointers or references to variables of a
390
          type compatible to the accessed variable. Dereferencing a pointer
391
          that violates the aliasing rules results in undefined behavior.
392
 
393
          In the case above, the compiler may assume that no access through an
394
          integer pointer can change the array a, consisting of shorts. Thus,
395
          printf may be called with the original values of a[0] and a[1]. What
396
          really happens is up to the compiler and may change with architecture
397
          and optimization level.
398
 
399
          Recent versions of GCC turn on the option -fstrict-aliasing (which
400
          allows alias-based optimizations) by default with -O2. And some
401
          architectures  then really print "1111 1111" as result. Without
402
          optimization the executable will generate the "expected" output "2222
403
          2222".
404
 
405
          To disable optimizations based on alias-analysis for faulty legacy
406
          code, the option -fno-strict-aliasing can be used as a work-around.
407
 
408
          The option -Wstrict-aliasing (which is included in -Wall) warns about
409
          some  - but not all - cases of violation of aliasing rules when
410
          -fstrict-aliasing is active.
411
 
412
          To fix the code above, you can use a union instead of a cast (note
413
          that  this  is  a GCC extension which might not work with other
414
          compilers):
415
 
416
#include 
417
 
418
int main()
419
{
420
  union
421
  {
422
    short a[2];
423
    int i;
424
  } u;
425
 
426
  u.a[0]=0x1111;
427
  u.a[1]=0x1111;
428
 
429
  u.i = 0x22222222;
430
 
431
  printf("%x %x\n", u.a[0], u.a[1]);
432
  return 0;
433
}
434
 
435
          Now the result will always be "2222 2222".
436
 
437
          For  some  more insight into the subject, please have a look at
438
          [33]this article.
439
 
440
   Cannot use preprocessor directive in macro arguments.
441
          Let me guess... you used an older version of GCC to compile code that
442
          looks something like this:
443
 
444
  memcpy(dest, src,
445
#ifdef PLATFORM1
446
         12
447
#else
448
         24
449
#endif
450
        );
451
 
452
          and you got a whole pile of error messages:
453
 
454
test.c:11: warning: preprocessing directive not recognized within macro arg
455
test.c:11: warning: preprocessing directive not recognized within macro arg
456
test.c:11: warning: preprocessing directive not recognized within macro arg
457
test.c: In function `foo':
458
test.c:6: undefined or invalid # directive
459
test.c:8: undefined or invalid # directive
460
test.c:9: parse error before `24'
461
test.c:10: undefined or invalid # directive
462
 
463
          This is because your C library's  happens to define memcpy
464
          as a macro - which is perfectly legitimate. In recent versions of
465
          glibc,  for  example, printf is among those functions which are
466
          implemented as macros.
467
 
468
          Versions of GCC prior to 3.3 did not allow you to put #ifdef (or any
469
          other preprocessor directive) inside the arguments of a macro. The
470
          code therefore would not compile.
471
 
472
          As of GCC 3.3 this kind of construct is always accepted and the
473
          preprocessor will probably do what you expect, but see the manual for
474
          detailed semantics.
475
 
476
          However,  this  kind  of code is not portable. It is "undefined
477
          behavior" according to the C standard; that means different compilers
478
          may do different things with it. It is always possible to rewrite
479
          code which uses conditionals inside macros so that it doesn't. You
480
          could write the above example
481
 
482
#ifdef PLATFORM1
483
   memcpy(dest, src, 12);
484
#else
485
   memcpy(dest, src, 24);
486
#endif
487
 
488
          This is a bit more typing, but I personally think it's better style
489
          in addition to being more portable.
490
 
491
   Cannot initialize a static variable with stdin.
492
          This has nothing to do with GCC, but people ask us about it a lot.
493
          Code like this:
494
 
495
#include 
496
 
497
FILE *yyin = stdin;
498
 
499
          will not compile with GNU libc, because stdin is not a constant. This
500
          was  done  deliberately,  to  make it easier to maintain binary
501
          compatibility  when  the  type  FILE needs to be changed. It is
502
          surprising for people used to traditional Unix C libraries, but it is
503
          permitted by the C standard.
504
 
505
          This construct commonly occurs in code generated by old versions of
506
          lex  or yacc. We suggest you try regenerating the parser with a
507
          current version of flex or bison, respectively. In your own code, the
508
          appropriate fix is to move the initialization to the beginning of
509
          main.
510
 
511
          There  is  a  common  misconception that the GCC developers are
512
          responsible for GNU libc. These are in fact two entirely separate
513
          projects; please check the [34]GNU libc web pages for details.
514
     _________________________________________________________________
515
 
516
C++
517
 
518
   Nested classes can access private members and types of the containing class.
519
          Defect report 45 clarifies that nested classes are members of the
520
          class  they are nested in, and so are granted access to private
521
          members of that class.
522
 
523
   G++ emits two copies of constructors and destructors.
524
          In general there are three types of constructors (and destructors).
525
 
526
         1. The complete object constructor/destructor.
527
         2. The base object constructor/destructor.
528
         3. The allocating constructor/deallocating destructor.
529
 
530
          The first two are different, when virtual base classes are involved.
531
 
532
   Global destructors are not run in the correct order.
533
          Global  destructors should be run in the reverse order of their
534
          constructors  completing. In most cases this is the same as the
535
          reverse  order  of  constructors  starting, but sometimes it is
536
          different, and that is important. You need to compile and link your
537
          programs with --use-cxa-atexit. We have not turned this switch on by
538
          default, as it requires a cxa aware runtime library (libc, glibc, or
539
          equivalent).
540
 
541
   Classes in exception specifiers must be complete types.
542
          [15.4]/1  tells you that you cannot have an incomplete type, or
543
          pointer  to  incomplete  (other than cv void *) in an exception
544
          specification.
545
 
546
   Exceptions don't work in multithreaded applications.
547
          You  need  to  rebuild g++ and libstdc++ with --enable-threads.
548
          Remember, C++ exceptions are not like hardware interrupts. You cannot
549
          throw an exception in one thread and catch it in another. You cannot
550
          throw an exception from a signal handler and catch it in the main
551
          thread.
552
 
553
   Templates, scoping, and digraphs.
554
          If you have a class in the global namespace, say named X, and want to
555
          give it as a template argument to some other class, say std::vector,
556
          then std::vector<::X> fails with a parser error.
557
 
558
          The reason is that the standard mandates that the sequence <: is
559
          treated  as  if  it  were  the token [. (There are several such
560
          combinations of characters - they are called digraphs.) Depending on
561
          the version, the compiler then reports a parse error before the
562
          character : (the colon before X) or a missing closing bracket ].
563
 
564
          The simplest way to avoid this is to write std::vector< ::X>, i.e.
565
          place  a  space between the opening angle bracket and the scope
566
          operator.
567
 
568
   Copy constructor access check while initializing a reference.
569
          Consider this code:
570
 
571
class A
572
{
573
public:
574
  A();
575
 
576
private:
577
  A(const A&);   // private copy ctor
578
};
579
 
580
A makeA(void);
581
void foo(const A&);
582
 
583
void bar(void)
584
{
585
  foo(A());       // error, copy ctor is not accessible
586
  foo(makeA());   // error, copy ctor is not accessible
587
 
588
  A a1;
589
  foo(a1);        // OK, a1 is a lvalue
590
}
591
 
592
          Starting with GCC 3.4.0, binding an rvalue to a const reference
593
          requires an accessible copy constructor. This might be surprising at
594
          first sight, especially since most popular compilers do not correctly
595
          implement this rule.
596
 
597
          The C++ Standard says that a temporary object should be created in
598
          this context and its contents filled with a copy of the object we are
599
          trying to bind to the reference; it also says that the temporary copy
600
          can be elided, but the semantic constraints (eg. accessibility) of
601
          the copy constructor still have to be checked.
602
 
603
          For further information, you can consult the following paragraphs of
604
          the C++ standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and
605
          [class.temporary]/2.
606
 
607
  Common problems when upgrading the compiler
608
 
609
    ABI changes
610
 
611
   The C++ application binary interface (ABI) consists of two components: the
612
   first defines how the elements of classes are laid out, how functions are
613
   called, how function names are mangled, etc; the second part deals with the
614
   internals of the objects in libstdc++. Although we strive for a non-changing
615
   ABI, so far we have had to modify it with each major release. If you change
616
   your compiler to a different major release you must recompile all libraries
617
   that contain C++ code. If you fail to do so you risk getting linker errors
618
   or malfunctioning programs. Some of our Java support libraries also contain
619
   C++ code, so you might want to recompile all libraries to be safe. It should
620
   not be necessary to recompile if you have changed to a bug-fix release of
621
   the same version of the compiler; bug-fix releases are careful to avoid ABI
622
   changes. See also the [35]compatibility section of the GCC manual.
623
 
624
   Remark: A major release is designated by a change to the first or second
625
   component  of the two- or three-part version number. A minor (bug-fix)
626
   release is designated by a change to the third component only. Thus GCC 3.2
627
   and 3.3 are major releases, while 3.3.1 and 3.3.2 are bug-fix releases for
628
   GCC 3.3. With the 3.4 series we are introducing a new naming scheme; the
629
   first release of this series is 3.4.0 instead of just 3.4.
630
 
631
    Standard conformance
632
 
633
   With each release, we try to make G++ conform closer to the ISO C++ standard
634
   (available  at  [36]http://www.ncits.org/cplusplus.htm).  We have also
635
   implemented  some of the core and library defect reports (available at
636
   [37]http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html     &
637
   [38]http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html
638
   respectively).
639
 
640
   Non-conforming legacy code that worked with older versions of GCC may be
641
   rejected by more recent compilers. There is no command-line switch to ensure
642
   compatibility in general, because trying to parse standard-conforming and
643
   old-style  code  at  the  same  time  would  render  the  C++ frontend
644
   unmaintainable. However, some non-conforming constructs are allowed when the
645
   command-line option -fpermissive is used.
646
 
647
   Two  milestones in standard conformance are GCC 3.0 (including a major
648
   overhaul of the standard library) and the 3.4.0 version (with its new C++
649
   parser).
650
 
651
    New in GCC 3.0
652
 
653
     * The  standard  library is much more conformant, and uses the std::
654
       namespace (which is now a real namespace, not an alias for ::).
655
     * The standard header files for the c library don't end with .h, but begin
656
       with c (i.e.  rather than ). The .h names are still
657
       available, but are deprecated.
658
     *  is deprecated, use  instead.
659
     * streambuf::seekoff  &  streambuf::seekpos are private, instead use
660
       streambuf::pubseekoff & streambuf::pubseekpos respectively.
661
     * If std::operator << (std::ostream &, long long) doesn't exist, you need
662
       to recompile libstdc++ with --enable-long-long.
663
 
664
   If you get lots of errors about things like cout not being found, you've
665
   most likely forgotten to tell the compiler to look in the std:: namespace.
666
   There are several ways to do this:
667
     * Say std::cout at the call. This is the most explicit way of saying what
668
       you mean.
669
     * Say using std::cout; somewhere before the call. You will need to do this
670
       for each function or type you wish to use from the standard library.
671
     * Say  using  namespace  std; somewhere before the call. This is the
672
       quick-but-dirty fix. This brings the whole of the std:: namespace into
673
       scope. Never do this in a header file, as every user of your header file
674
       will be affected by this decision.
675
 
676
    New in GCC 3.4.0
677
 
678
   The  new  parser  brings  a lot of improvements, especially concerning
679
   name-lookup.
680
     * The "implicit typename" extension got removed (it was already deprecated
681
       since GCC 3.1), so that the following code is now rejected, see [14.6]:
682
 
683
template  struct A
684
{
685
    typedef int X;
686
};
687
 
688
template  struct B
689
{
690
    A::X          x;  // error
691
    typename A::X y;  // OK
692
};
693
 
694
B b;
695
 
696
     * For  similar reasons, the following code now requires the template
697
       keyword, see [14.2]:
698
 
699
template  struct A
700
{
701
    template  struct X {};
702
};
703
 
704
template  struct B
705
{
706
    typename A::X<0>          x;  // error
707
    typename A::template X<0> y;  // OK
708
};
709
 
710
B b;
711
 
712
     * We  now  have two-stage name-lookup, so that the following code is
713
       rejected, see [14.6]/9:
714
 
715
template  int foo()
716
{
717
    return i;  // error
718
}
719
 
720
     * This also affects members of base classes, see [14.6.2]:
721
 
722
template  struct A
723
{
724
    int i, j;
725
};
726
 
727
template  struct B : A
728
{
729
    int foo1() { return i; }       // error
730
    int foo2() { return this->i; } // OK
731
    int foo3() { return B::i; } // OK
732
    int foo4() { return A::i; } // OK
733
 
734
    using A::j;
735
    int foo5() { return j; }       // OK
736
};
737
 
738
   In addition to the problems listed above, the manual contains a section on
739
   [39]Common Misunderstandings with GNU C++.
740
 
741
References
742
 
743
   1. http://gcc.gnu.org/bugs.html
744
   2. http://gcc.gnu.org/bugs.html#report
745
   3. http://gcc.gnu.org/bugs.html#need
746
   4. http://gcc.gnu.org/bugs.html#dontwant
747
   5. http://gcc.gnu.org/bugs.html#where
748
   6. http://gcc.gnu.org/bugs.html#detailed
749
   7. http://gcc.gnu.org/bugs.html#gnat
750
   8. http://gcc.gnu.org/bugs.html#pch
751
   9. http://gcc.gnu.org/bugs.html#known
752
  10. http://gcc.gnu.org/bugs.html#cxx
753
  11. http://gcc.gnu.org/bugs.html#missing
754
  12. http://gcc.gnu.org/bugs.html#fixed34
755
  13. http://gcc.gnu.org/bugs.html#fortran
756
  14. http://gcc.gnu.org/bugs.html#nonbugs
757
  15. http://gcc.gnu.org/bugs.html#nonbugs_general
758
  16. http://gcc.gnu.org/bugs.html#nonbugs_c
759
  17. http://gcc.gnu.org/bugs.html#nonbugs_cxx
760
  18. http://gcc.gnu.org/bugs.html#upgrading
761
  19. http://gcc.gnu.org/bugs.html#known
762
  20. http://gcc.gnu.org/bugzilla/
763
  21. mailto:gcc-bugs@gcc.gnu.org
764
  22. http://gcc.gnu.org/bugs.html#gnat
765
  23. http://gcc.gnu.org/bugs.html#pch
766
  24. http://gcc.gnu.org/bugs.html#detailed
767
  25. http://gcc.gnu.org/bugs.html#where
768
  26. http://gcc.gnu.org/bugs.html#detailed
769
  27. http://gcc.gnu.org/bugs.html#detailed
770
  28. http://gcc.gnu.org/bugs.html#new34
771
  29. http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Trouble.html
772
  30. http://gcc.gnu.org/PR323
773
  31. http://www.validlab.com/goldberg/paper.ps
774
  32. http://gcc.gnu.org/PR11751
775
  33. http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html
776
  34. http://www.gnu.org/software/libc/
777
  35. http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html
778
  36. http://www.ncits.org/cplusplus.htm
779
  37. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html
780
  38. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html
781
  39. http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.