PATCH: bugs.html

[Gerald Pfeifer]

This patch was contributed by Joe, with some (very) minor refinements by
myself:

  Replace "egcs" by "GCC 2.95".  Remove a bug that was fixed between egcs
  1.1 and egcs 1.1.1.  Use <CODE> to flag keywords.  Minor improvements.

Installed.
Gerald

Index: bugs.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/bugs.html,v
retrieving revision 1.5
diff -r1.5 bugs.html
3c3
< <title>EGCS Frequently Detected Bugs</title>
---
> <title>Frequently Reported Bugs in GCC 2.95</title>
6c6
< <h1 align="center">Frequently reported bugs of the EGCS compilers</h1>
---
> <h1 align="center">Frequently Reported Bugs in GCC 2.95</h1>
9c9
< http://egcs.cygnus.com/bugs.html "> http://egcs.cygnus.com/bugs.html </a>.
---
> http://gcc.gnu.org/bugs.html "> http://gcc.gnu.org/bugs.html </a>.
20c20,21
< <p>This is the list of bugs in g++ that are reported very often, yet not
---
> <p>This is the list of bugs in g++ (aka GNU C++) that are reported very often,
> but not yet
37,40c38,40
< <p>You should try to use the latest stable release of the EGCS C++
< compiler. This is currently 1.1. Many commonly reported bugs in earlier
< releases are fixed in that version. 
< 
---
> <p>You should try to use the latest stable release of the GNU C++
> compiler. This is currently 2.95. Many commonly reported bugs in earlier
> releases are fixed in that version.
43c43
< egcs 1.1 incorrectly accepts code like
---
> GCC 2.95 incorrectly accepts code like
53c53,54
< Since Y is a private member of Y, the definition of z should be
---
> Since <CODE>Y</CODE> is a private member of <CODE>X</CODE>,
> the definition of <CODE>z</CODE> should be
59,60c60,62
< As of egcs 1.1, the export keyword is not implemented. It allows
< to move definitions of templates out of header files; exported
---
> As of GCC 2.95, the <CODE>export</CODE> keyword is not implemented. 
> This feature, when implemented, will permit moving
> definitions of templates out of header files; exported
85c87,88
< Even though X::i is protected, it is redeclared public in Y.
---
> Even though <CODE>X::i</CODE> is protected, it is redeclared public in
> <CODE>Y</CODE>.
87c90
< <p>Standard C++ extends this notion and aligns it with using
---
> <p>Standard C++ extends this notion and aligns it with <CODE>using</CODE>
89c92
< code is also valid
---
> code is also valid:
109,110c112,113
< A using declaration not only redeclares access, it also allows to
< merge functions from the base class into the derived class, which is
---
> A <CODE>using</CODE> declaration not only redeclares access, it also permits
> merging functions from the base class into the derived class, which is
112c115
< equivalent to using declarations.
---
> equivalent to <CODE>using</CODE> declarations.
114,115c117,118
< <p>egcs 1.1 rejects this code. It treats using declarations in the
< same way as ARM-style access declarations.
---
> <p>GCC 2.95 rejects this code. It treats <CODE>using</CODE> declarations in
> the same way as ARM-style access declarations.
118,119c121,122
< Up to and including egcs 1.2, the compiler will produce a parse error 
< for the return statement in
---
> Up to and including GCC 2.95, the compiler will produce a parse error 
> for the <CODE>return</CODE> statement in
135,138c138,141
< This problem is that the compiler interprets A() as a function (taking
< no arguments, returning A), and (A()) as a cast - with a missing
< expression, hence the parse error. The work-around is to omit the
< parentheses:
---
> The problem is that the compiler interprets <CODE>A()</CODE> as a
> function (taking no arguments, returning <CODE>A</CODE>), and
> <CODE>(A()</CODE>) as a cast - with a missing expression, hence the
> parse error. The work-around is to omit the parentheses:
143c146
< This problem occurs in a number of variants; in throw statements,
---
> This problem occurs in a number of variants; in <CODE>throw</CODE> statements,
152,155c155,162
< <p>Many of the standard library features are not implemented in egcs
< 1.1. Others, such as iostreams, are supported, but not in a
< complianted way (e.g. ostream is not basic_ostream&#lt;char>, and not
< declared in std::).
---
> <p>Many of the standard library features are not implemented in GCC
> 2.95. Others, such as iostreams, are supported, but not in a
> compliant way (e.g. <CODE>ostream</CODE> is not
> <CODE>basic_ostream&#lt;char&#gt;</CODE>, and not
> declared in <CODE>std::</CODE>).
> 
> <p>SGI's implementation of the STL is included, but it is in the
> global namespace, not in <CODE>std::</CODE>.
161,177d167
< <h3>G++ crashes on destructor with arguments</h3>
< If you compile the program
< <pre>
< struct A{
<   virtual ~A();
< };
< 
< A::~A(int)
< {}
< </pre>
< with egcs 1.1 or earlier, it will report an internal compiler
< error. The program is ill-formed, of course (a destructor does not
< have arguments); however, g++ should not crash.
< <p>
< This bug is fixed in egcs 1.1.1 (2.91.60), as well as in the
< development branch (2.92.21 and later)
< 
179c169
< <p>Although allowed by the standard, egcs 1.1 will report an
---
> <p>Although allowed by the standard, GCC 2.95 will report an
188,190c178,180
< <p><a href="index.html">Return to the EGCS home page</a>  
< <a href="faq.html">Return to the EGCS FAQ</a>
< <p><i>Last modified:  May  3, 1999</i>
---
> <p><a href="index.html">Return to the GCC home page</a>  
> <a href="faq.html">Return to the GCC FAQ</a>
> <p><i>Last modified:  July 28, 1999</i>