?rev1line? |
?rev2line? |
|
|
|
GCC Bugs
|
|
|
|
The latest version of this document is always available at
|
|
[1]http://gcc.gnu.org/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]Detailed bug reporting instructions when using a precompiled
|
|
header
|
|
* [9]Frequently Reported Bugs in GCC
|
|
+ [10]C++
|
|
o [11]Missing features
|
|
o [12]Bugs fixed in the 3.4 series
|
|
+ [13]Fortran
|
|
* [14]Non-bugs
|
|
+ [15]General
|
|
+ [16]C
|
|
+ [17]C++
|
|
o [18]Common problems when upgrading the compiler
|
|
_________________________________________________________________
|
|
|
|
Reporting Bugs
|
|
|
|
The main purpose of a bug report is to enable us to fix the bug. The most
|
|
important prerequisite for this is that the report must be complete and
|
|
self-contained.
|
|
|
|
Before you report a bug, please check the [19]list of well-known bugs and,
|
|
if possible, try a current development snapshot. If you want to report a bug
|
|
with versions of GCC before 3.4 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)
|
|
* Assembly files (*.s) produced by the compiler, or any binary files, such
|
|
as object files, executables, core files, or precompiled header 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 bug database.
|
|
Alternatively, you can use the gccbug script that mails your bug report to
|
|
the bug database.
|
|
Only if all this is absolutely impossible, mail all information to
|
|
[21]gcc-bugs@gcc.gnu.org.
|
|
|
|
Detailed bug reporting instructions
|
|
|
|
Please refer to the [22]next section when reporting bugs in GNAT, the Ada
|
|
compiler, or to the [23]one after that when reporting bugs that appear when
|
|
using a precompiled header.
|
|
|
|
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
|
|
|
|
The only excuses to not send us the preprocessed sources are (i) if you've
|
|
found a bug in the preprocessor, (ii) if you've reduced the testcase to a
|
|
small file that doesn't include any other file or (iii) if the bug appears
|
|
only when using precompiled headers. 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.
|
|
|
|
Please avoid posting an archive (.tar, .shar or .zip); we generally need
|
|
just a single file to reproduce the bug (the .i/.ii/.f preprocessed file),
|
|
and, by storing it in an archive, you're just making our volunteers' jobs
|
|
harder. Only when your bug report requires multiple source files to be
|
|
reproduced should you use an archive. This is, for example, the case if you
|
|
are using INCLUDE directives in Fortran code, which are not processed by the
|
|
preprocessor, but the compiler. In that case, we need the main file and all
|
|
INCLUDEd files. In any case, make sure the compiler version, error message,
|
|
etc, are included in the body of your bug report as plain text, even if
|
|
needlessly duplicated as part of an archive.
|
|
|
|
Detailed bug reporting instructions for GNAT
|
|
|
|
See the [24]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 according to our [25]generic instructions. (If you use a mailing list for
|
|
reporting, please include an "[Ada]" tag in the subject.)
|
|
|
|
Detailed bug reporting instructions when using a precompiled header
|
|
|
|
If you're encountering a bug when using a precompiled header, the first
|
|
thing to do is to delete the precompiled header, and try running the same
|
|
GCC command again. If the bug happens again, the bug doesn't really involve
|
|
precompiled headers, please report it without using them by following the
|
|
instructions [26]above.
|
|
|
|
If you've found a bug while building a precompiled header (for instance, the
|
|
compiler crashes), follow the usual instructions [27]above.
|
|
|
|
If you've found a real precompiled header bug, what we'll need to reproduce
|
|
it is the sources to build the precompiled header (as a single .i file), the
|
|
source file that uses the precompiled header, any other headers that source
|
|
file includes, and the command lines that you used to build the precompiled
|
|
header and to use it.
|
|
|
|
Please don't send us the actual precompiled header. It is likely to be very
|
|
large and we can't use it to reproduce the problem.
|
|
_________________________________________________________________
|
|
|
|
Frequently Reported Bugs in GCC
|
|
|
|
This is a list of bugs in GCC that are reported very often, but not yet
|
|
fixed. While it is certainly better to fix bugs instead of documenting them,
|
|
this document might save people the effort of writing a bug report when the
|
|
bug is already well-known.
|
|
|
|
There are many reasons why a reported bug doesn't get fixed. It might be
|
|
difficult to fix, or fixing it might break compatibility. Often, reports get
|
|
a low priority when there is a simple work-around. In particular, bugs
|
|
caused by invalid code have a simple work-around: fix the code.
|
|
_________________________________________________________________
|
|
|
|
C++
|
|
|
|
Missing features
|
|
|
|
The export keyword is not implemented.
|
|
Most C++ compilers (G++ included) do not yet implement export, which
|
|
is necessary for separate compilation of template declarations and
|
|
definitions. Without export, a template definition must be in scope
|
|
to be used. The obvious workaround is simply to place all definitions
|
|
in the header itself. Alternatively, the compilation unit containing
|
|
template definitions may be included from the header.
|
|
|
|
Bugs fixed in the 3.4 series
|
|
|
|
The following bugs are present up to (and including) GCC 3.3.x. They have
|
|
been fixed in 3.4.0.
|
|
|
|
Two-stage name-lookup.
|
|
GCC did not implement two-stage name-lookup (also see [28]below).
|
|
|
|
Covariant return types.
|
|
GCC did not implement non-trivial covariant returns.
|
|
|
|
Parse errors for "simple" code.
|
|
GCC gave parse errors for seemingly simple code, such as
|
|
|
|
struct A
|
|
{
|
|
A();
|
|
A(int);
|
|
};
|
|
|
|
struct B
|
|
{
|
|
B(A);
|
|
B(A,A);
|
|
void foo();
|
|
};
|
|
|
|
A bar()
|
|
{
|
|
B b(A(),A(1)); // Variable b, initialized with two temporaries
|
|
B(A(2)).foo(); // B temporary, initialized with A temporary
|
|
return (A()); // return A temporary
|
|
}
|
|
|
|
Although being valid code, each of the three lines with a comment was
|
|
rejected by GCC. The work-arounds for older compiler versions
|
|
proposed below do not change the semantics of the programs at all.
|
|
|
|
The problem in the first case was that GCC started to parse the
|
|
declaration of b as a function called b returning B, taking a
|
|
function returning A as an argument. When it encountered the 1, it
|
|
was too late. To show the compiler that this should be really an
|
|
expression, a comma operator with a dummy argument could be used:
|
|
|
|
B b((0,A()),A(1));
|
|
|
|
The work-around for simpler cases like the second one was to add
|
|
additional parentheses around the expressions that were mistaken as
|
|
declarations:
|
|
|
|
(B(A(2))).foo();
|
|
|
|
In the third case, however, additional parentheses were causing the
|
|
problems: The compiler interpreted A() as a function (taking no
|
|
arguments, returning A), and (A()) as a cast lacking an expression to
|
|
be casted, hence the parse error. The work-around was to omit the
|
|
parentheses:
|
|
|
|
return A();
|
|
|
|
This problem occurred in a number of variants; in throw statements,
|
|
people also frequently put the object in parentheses.
|
|
_________________________________________________________________
|
|
|
|
Fortran
|
|
|
|
G77 bugs are documented in the G77 manual rather than explicitly listed
|
|
here. Please see [29]Known Causes of Trouble with GNU Fortran in the G77
|
|
manual.
|
|
_________________________________________________________________
|
|
|
|
Non-bugs
|
|
|
|
The following are not actually bugs, but are reported often enough to
|
|
warrant a mention here.
|
|
|
|
It is not always a bug in the compiler, if code which "worked" in a previous
|
|
version, is now rejected. Earlier versions of GCC sometimes were less picky
|
|
about standard conformance and accepted invalid source code. In addition,
|
|
programming languages themselves change, rendering code invalid that used to
|
|
be conforming (this holds especially for C++). In either case, you should
|
|
update your code to match recent language standards.
|
|
_________________________________________________________________
|
|
|
|
General
|
|
|
|
Problems with floating point numbers - the [30]most often reported non-bug.
|
|
In a number of cases, GCC appears to perform floating point
|
|
computations incorrectly. For example, the C++ program
|
|
|
|
#include
|
|
|
|
int main()
|
|
{
|
|
double a = 0.5;
|
|
double b = 0.01;
|
|
std::cout << (int)(a / b) << std::endl;
|
|
return 0;
|
|
}
|
|
|
|
might print 50 on some systems and optimization levels, and 49 on
|
|
others.
|
|
|
|
This is the result of rounding: The computer cannot represent all
|
|
real numbers exactly, so it has to use approximations. When computing
|
|
with approximation, the computer needs to round to the nearest
|
|
representable number.
|
|
|
|
This is not a bug in the compiler, but an inherent limitation of the
|
|
floating point types. Please study [31]this paper for more
|
|
information.
|
|
_________________________________________________________________
|
|
|
|
C
|
|
|
|
Increment/decrement operator (++/--) not working as expected - a [32]problem
|
|
with many variations.
|
|
The following expressions have unpredictable results:
|
|
|
|
x[i]=++i
|
|
foo(i,++i)
|
|
i*(++i) /* special case with foo=="operator*" */
|
|
std::cout << i << ++i /* foo(foo(std::cout,i),++i) */
|
|
|
|
since the i without increment can be evaluated before or after ++i.
|
|
|
|
The C and C++ standards have the notion of "sequence points".
|
|
Everything that happens between two sequence points happens in an
|
|
unspecified order, but it has to happen after the first and before
|
|
the second sequence point. The end of a statement and a function call
|
|
are examples for sequence points, whereas assignments and the comma
|
|
between function arguments are not.
|
|
|
|
Modifying a value twice between two sequence points as shown in the
|
|
following examples is even worse:
|
|
|
|
i=++i
|
|
foo(++i,++i)
|
|
(++i)*(++i) /* special case with foo=="operator*" */
|
|
std::cout << ++i << ++i /* foo(foo(std::cout,++i),++i) */
|
|
|
|
This leads to undefined behavior (i.e. the compiler can do anything).
|
|
|
|
Casting does not work as expected when optimization is turned on.
|
|
This is often caused by a violation of aliasing rules, which are part
|
|
of the ISO C standard. These rules say that a program is invalid if
|
|
you try to access a variable through a pointer of an incompatible
|
|
type. This is happening in the following example where a short is
|
|
accessed through a pointer to integer (the code assumes 16-bit shorts
|
|
and 32-bit ints):
|
|
|
|
#include
|
|
|
|
int main()
|
|
{
|
|
short a[2];
|
|
|
|
a[0]=0x1111;
|
|
a[1]=0x1111;
|
|
|
|
*(int *)a = 0x22222222; /* violation of aliasing rules */
|
|
|
|
printf("%x %x\n", a[0], a[1]);
|
|
return 0;
|
|
}
|
|
|
|
The aliasing rules were designed to allow compilers more aggressive
|
|
optimization. Basically, a compiler can assume that all changes to
|
|
variables happen through pointers or references to variables of a
|
|
type compatible to the accessed variable. Dereferencing a pointer
|
|
that violates the aliasing rules results in undefined behavior.
|
|
|
|
In the case above, the compiler may assume that no access through an
|
|
integer pointer can change the array a, consisting of shorts. Thus,
|
|
printf may be called with the original values of a[0] and a[1]. What
|
|
really happens is up to the compiler and may change with architecture
|
|
and optimization level.
|
|
|
|
Recent versions of GCC turn on the option -fstrict-aliasing (which
|
|
allows alias-based optimizations) by default with -O2. And some
|
|
architectures then really print "1111 1111" as result. Without
|
|
optimization the executable will generate the "expected" output "2222
|
|
2222".
|
|
|
|
To disable optimizations based on alias-analysis for faulty legacy
|
|
code, the option -fno-strict-aliasing can be used as a work-around.
|
|
|
|
The option -Wstrict-aliasing (which is included in -Wall) warns about
|
|
some - but not all - cases of violation of aliasing rules when
|
|
-fstrict-aliasing is active.
|
|
|
|
To fix the code above, you can use a union instead of a cast (note
|
|
that this is a GCC extension which might not work with other
|
|
compilers):
|
|
|
|
#include
|
|
|
|
int main()
|
|
{
|
|
union
|
|
{
|
|
short a[2];
|
|
int i;
|
|
} u;
|
|
|
|
u.a[0]=0x1111;
|
|
u.a[1]=0x1111;
|
|
|
|
u.i = 0x22222222;
|
|
|
|
printf("%x %x\n", u.a[0], u.a[1]);
|
|
return 0;
|
|
}
|
|
|
|
Now the result will always be "2222 2222".
|
|
|
|
For some more insight into the subject, please have a look at
|
|
[33]this article.
|
|
|
|
Cannot use preprocessor directive in macro arguments.
|
|
Let me guess... you used an older version of GCC to compile 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
|
|
|
|
This is because your C library's happens to define memcpy
|
|
as a macro - which is perfectly legitimate. In recent versions of
|
|
glibc, for example, printf is among those functions which are
|
|
implemented as macros.
|
|
|
|
Versions of GCC prior to 3.3 did not allow you to put #ifdef (or any
|
|
other preprocessor directive) inside the arguments of a macro. The
|
|
code therefore would not compile.
|
|
|
|
As of GCC 3.3 this kind of construct is always accepted and the
|
|
preprocessor will probably do what you expect, but see the manual for
|
|
detailed semantics.
|
|
|
|
However, this kind of code is not portable. It is "undefined
|
|
behavior" according to the C standard; that means different compilers
|
|
may do different things with it. It is always possible to rewrite
|
|
code which uses conditionals inside macros so that it doesn't. You
|
|
could write the above example
|
|
|
|
#ifdef PLATFORM1
|
|
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.
|
|
|
|
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
|
|
|
|
FILE *yyin = stdin;
|
|
|
|
will not compile with GNU libc, because stdin is not a constant. This
|
|
was done deliberately, to make it easier to maintain binary
|
|
compatibility when the type FILE needs to be changed. It is
|
|
surprising for people used to traditional Unix C libraries, but it is
|
|
permitted by the C standard.
|
|
|
|
This construct commonly occurs in code generated by old versions of
|
|
lex or yacc. We suggest you try regenerating the parser with a
|
|
current version of flex or bison, respectively. In your own code, the
|
|
appropriate fix is to move the initialization to the beginning of
|
|
main.
|
|
|
|
There is a common misconception that the GCC developers are
|
|
responsible for GNU libc. These are in fact two entirely separate
|
|
projects; please check the [34]GNU libc web pages for details.
|
|
_________________________________________________________________
|
|
|
|
C++
|
|
|
|
Nested classes can access private members and types of the containing class.
|
|
Defect report 45 clarifies that nested classes are members of the
|
|
class they are nested in, and so are granted access to private
|
|
members of that class.
|
|
|
|
G++ emits two copies of constructors and destructors.
|
|
In general there are three types of constructors (and destructors).
|
|
|
|
1. The complete object constructor/destructor.
|
|
2. The base object constructor/destructor.
|
|
3. The allocating constructor/deallocating destructor.
|
|
|
|
The first two are different, when virtual base classes are involved.
|
|
|
|
Global destructors are not run in the correct order.
|
|
Global destructors should be run in the reverse order of their
|
|
constructors completing. In most cases this is the same as the
|
|
reverse order of constructors starting, but sometimes it is
|
|
different, and that is important. You need to compile and link your
|
|
programs with --use-cxa-atexit. We have not turned this switch on by
|
|
default, as it requires a cxa aware runtime library (libc, glibc, or
|
|
equivalent).
|
|
|
|
Classes in exception specifiers must be complete types.
|
|
[15.4]/1 tells you that you cannot have an incomplete type, or
|
|
pointer to incomplete (other than cv void *) in an exception
|
|
specification.
|
|
|
|
Exceptions don't work in multithreaded applications.
|
|
You need to rebuild g++ and libstdc++ with --enable-threads.
|
|
Remember, C++ exceptions are not like hardware interrupts. You cannot
|
|
throw an exception in one thread and catch it in another. You cannot
|
|
throw an exception from a signal handler and catch it in the main
|
|
thread.
|
|
|
|
Templates, scoping, and digraphs.
|
|
If you have a class in the global namespace, say named X, and want to
|
|
give it as a template argument to some other class, say std::vector,
|
|
then std::vector<::X> fails with a parser error.
|
|
|
|
The reason is that the standard mandates that the sequence <: is
|
|
treated as if it were the token [. (There are several such
|
|
combinations of characters - they are called digraphs.) Depending on
|
|
the version, the compiler then reports a parse error before the
|
|
character : (the colon before X) or a missing closing bracket ].
|
|
|
|
The simplest way to avoid this is to write std::vector< ::X>, i.e.
|
|
place a space between the opening angle bracket and the scope
|
|
operator.
|
|
|
|
Copy constructor access check while initializing a reference.
|
|
Consider this code:
|
|
|
|
class A
|
|
{
|
|
public:
|
|
A();
|
|
|
|
private:
|
|
A(const A&); // private copy ctor
|
|
};
|
|
|
|
A makeA(void);
|
|
void foo(const A&);
|
|
|
|
void bar(void)
|
|
{
|
|
foo(A()); // error, copy ctor is not accessible
|
|
foo(makeA()); // error, copy ctor is not accessible
|
|
|
|
A a1;
|
|
foo(a1); // OK, a1 is a lvalue
|
|
}
|
|
|
|
Starting with GCC 3.4.0, binding an rvalue to a const reference
|
|
requires an accessible copy constructor. This might be surprising at
|
|
first sight, especially since most popular compilers do not correctly
|
|
implement this rule.
|
|
|
|
The C++ Standard says that a temporary object should be created in
|
|
this context and its contents filled with a copy of the object we are
|
|
trying to bind to the reference; it also says that the temporary copy
|
|
can be elided, but the semantic constraints (eg. accessibility) of
|
|
the copy constructor still have to be checked.
|
|
|
|
For further information, you can consult the following paragraphs of
|
|
the C++ standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and
|
|
[class.temporary]/2.
|
|
|
|
Common problems when upgrading the compiler
|
|
|
|
ABI changes
|
|
|
|
The C++ application binary interface (ABI) consists of two components: the
|
|
first defines how the elements of classes are laid out, how functions are
|
|
called, how function names are mangled, etc; the second part deals with the
|
|
internals of the objects in libstdc++. Although we strive for a non-changing
|
|
ABI, so far we have had to modify it with each major release. If you change
|
|
your compiler to a different major release you must recompile all libraries
|
|
that contain C++ code. If you fail to do so you risk getting linker errors
|
|
or malfunctioning programs. Some of our Java support libraries also contain
|
|
C++ code, so you might want to recompile all libraries to be safe. It should
|
|
not be necessary to recompile if you have changed to a bug-fix release of
|
|
the same version of the compiler; bug-fix releases are careful to avoid ABI
|
|
changes. See also the [35]compatibility section of the GCC manual.
|
|
|
|
Remark: A major release is designated by a change to the first or second
|
|
component of the two- or three-part version number. A minor (bug-fix)
|
|
release is designated by a change to the third component only. Thus GCC 3.2
|
|
and 3.3 are major releases, while 3.3.1 and 3.3.2 are bug-fix releases for
|
|
GCC 3.3. With the 3.4 series we are introducing a new naming scheme; the
|
|
first release of this series is 3.4.0 instead of just 3.4.
|
|
|
|
Standard conformance
|
|
|
|
With each release, we try to make G++ conform closer to the ISO C++ standard
|
|
(available at [36]http://www.ncits.org/cplusplus.htm). We have also
|
|
implemented some of the core and library defect reports (available at
|
|
[37]http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html &
|
|
[38]http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html
|
|
respectively).
|
|
|
|
Non-conforming legacy code that worked with older versions of GCC may be
|
|
rejected by more recent compilers. There is no command-line switch to ensure
|
|
compatibility in general, because trying to parse standard-conforming and
|
|
old-style code at the same time would render the C++ frontend
|
|
unmaintainable. However, some non-conforming constructs are allowed when the
|
|
command-line option -fpermissive is used.
|
|
|
|
Two milestones in standard conformance are GCC 3.0 (including a major
|
|
overhaul of the standard library) and the 3.4.0 version (with its new C++
|
|
parser).
|
|
|
|
New in GCC 3.0
|
|
|
|
* The standard library is much more conformant, and uses the std::
|
|
namespace (which is now a real namespace, not an alias for ::).
|
|
* The standard header files for the c library don't end with .h, but begin
|
|
with c (i.e. rather than ). The .h names are still
|
|
available, but are deprecated.
|
|
* is deprecated, use 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.
|
|
|
|
If you get lots of errors about things like cout not being found, you've
|
|
most likely forgotten to tell the compiler to look in the std:: namespace.
|
|
There are several ways to do this:
|
|
* Say std::cout at the call. This is the most explicit way of saying what
|
|
you mean.
|
|
* Say using std::cout; somewhere before the call. You will need to do this
|
|
for each function or type you wish to use from the standard library.
|
|
* Say using namespace std; somewhere before the call. This is the
|
|
quick-but-dirty fix. This brings the whole of the std:: namespace into
|
|
scope. Never do this in a header file, as every user of your header file
|
|
will be affected by this decision.
|
|
|
|
New in GCC 3.4.0
|
|
|
|
The new parser brings a lot of improvements, especially concerning
|
|
name-lookup.
|
|
* The "implicit typename" extension got removed (it was already deprecated
|
|
since GCC 3.1), so that the following code is now rejected, see [14.6]:
|
|
|
|
template struct A
|
|
{
|
|
typedef int X;
|
|
};
|
|
|
|
template struct B
|
|
{
|
|
A::X x; // error
|
|
typename A::X y; // OK
|
|
};
|
|
|
|
B b;
|
|
|
|
* For similar reasons, the following code now requires the template
|
|
keyword, see [14.2]:
|
|
|
|
template struct A
|
|
{
|
|
template struct X {};
|
|
};
|
|
|
|
template struct B
|
|
{
|
|
typename A::X<0> x; // error
|
|
typename A::template X<0> y; // OK
|
|
};
|
|
|
|
B b;
|
|
|
|
* We now have two-stage name-lookup, so that the following code is
|
|
rejected, see [14.6]/9:
|
|
|
|
template int foo()
|
|
{
|
|
return i; // error
|
|
}
|
|
|
|
* This also affects members of base classes, see [14.6.2]:
|
|
|
|
template struct A
|
|
{
|
|
int i, j;
|
|
};
|
|
|
|
template struct B : A
|
|
{
|
|
int foo1() { return i; } // error
|
|
int foo2() { return this->i; } // OK
|
|
int foo3() { return B::i; } // OK
|
|
int foo4() { return A::i; } // OK
|
|
|
|
using A::j;
|
|
int foo5() { return j; } // OK
|
|
};
|
|
|
|
In addition to the problems listed above, the manual contains a section on
|
|
[39]Common Misunderstandings with GNU C++.
|
|
|
|
References
|
|
|
|
1. http://gcc.gnu.org/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#pch
|
|
9. http://gcc.gnu.org/bugs.html#known
|
|
10. http://gcc.gnu.org/bugs.html#cxx
|
|
11. http://gcc.gnu.org/bugs.html#missing
|
|
12. http://gcc.gnu.org/bugs.html#fixed34
|
|
13. http://gcc.gnu.org/bugs.html#fortran
|
|
14. http://gcc.gnu.org/bugs.html#nonbugs
|
|
15. http://gcc.gnu.org/bugs.html#nonbugs_general
|
|
16. http://gcc.gnu.org/bugs.html#nonbugs_c
|
|
17. http://gcc.gnu.org/bugs.html#nonbugs_cxx
|
|
18. http://gcc.gnu.org/bugs.html#upgrading
|
|
19. http://gcc.gnu.org/bugs.html#known
|
|
20. http://gcc.gnu.org/bugzilla/
|
|
21. mailto:gcc-bugs@gcc.gnu.org
|
|
22. http://gcc.gnu.org/bugs.html#gnat
|
|
23. http://gcc.gnu.org/bugs.html#pch
|
|
24. http://gcc.gnu.org/bugs.html#detailed
|
|
25. http://gcc.gnu.org/bugs.html#where
|
|
26. http://gcc.gnu.org/bugs.html#detailed
|
|
27. http://gcc.gnu.org/bugs.html#detailed
|
|
28. http://gcc.gnu.org/bugs.html#new34
|
|
29. http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Trouble.html
|
|
30. http://gcc.gnu.org/PR323
|
|
31. http://www.validlab.com/goldberg/paper.ps
|
|
32. http://gcc.gnu.org/PR11751
|
|
33. http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html
|
|
34. http://www.gnu.org/software/libc/
|
|
35. http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html
|
|
36. http://www.ncits.org/cplusplus.htm
|
|
37. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html
|
|
38. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html
|
|
39. http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html
|
